您还应该在单元测试中进行内存管理吗？ （OC 单位）
我还应该在单元测试中释放对象吗？
我注意到在Apple的“iPhoneUnitTests”示例项目中，设置方法中的对象是[[object alloc] init]，但从未在单元测试中的任何地方发布？
谢谢！
Should I still bother with releasing objects in a unit test?
I noticed in Apple's "iPhoneUnitTests" sample project objects are [[object alloc] init] in the setup method but never released anywhere in the unit test?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我仍然会进行适当的内存管理。
我觉得在不输入
release的情况下输入init或retain太脏了。这是一个好习惯。此外，正如 Epsilon Prime 在评论中提到的，能够测试泄漏是有用的。
I would still do proper memory management.
I feel too dirty typing
initorretainwithout typingrelease. It's a good habit to have.Also, as Epsilon Prime mentioned in the comments, being able to test for leaks is useful.
始终实行良好的内存管理是个好主意。它显然不会伤害你，即使它没有潜在的帮助。此外，更多地练习适当的内存管理（而不是说“它在这里不那么重要”）只会让你在重要的时候不太可能犯错误。
不要仅仅因为看到这样那样的示例代码不遵循最佳实践而放弃最佳实践。我的猜测是，这样的示例代码可能不是由那些拥有丰富经验的人编写的（因为这些人正在做更重要的工作），因此虽然示例代码可能演示了它想要展示的内容，但它通常不是最好的事情检查与样本的预期目的（例如最佳编码实践）正交的问题。
Its a good idea to always practice good memory management. It obviously can't hurt you, even if it doesn't potentially help. In addition, more practice with proper memory management (instead of saying "its not so important here") can only make you less likely to make mistakes down the road when it is important.
Don't abandon best practices just because you see such-and-such sample code that doesn't follow them. My guess is that such sample code probably isn't written by those with a lot of experience (because those people are doing more important jobs), so while the sample code may demonstrate what it's intended to show it usually isn't the best thing to examine for issues that are orthogonal to the sample's intended purpose (such a best coding practices).
两个测试套件都实践了正确的内存管理。
CalcTest 只是将变量分配给作为 AppDelegate 一部分存在的对象，即它从不保留它们，因此它从不“拥有”它们。
CalculatorTest 在tearDown 中释放它所拥有的对象，正如单元测试文档所规定的那样。
Both test suites do practice proper memory management.
CalcTest is merely assigning variables to objects that exist as part of the AppDelegate, i.e. it never retains them so it never 'owns' them.
CalculatorTest releases the objects it owns in tearDown, as it is supposed to per the unit testing documentation.
我想说它仍然很重要，是的，但不像在实际代码中查找泄漏那么重要。泄漏的单元测试可能会占用更多内存，特别是如果您选择不释放任何内容。另外，如果您在 Instruments 中运行单元测试来查找泄漏（我有时会这样做，因为我正在测试框架而不是普通应用程序），泄漏单元测试可能会分散您试图查找的实际泄漏的注意力。
示例代码可能很快而且很脏，但这绝不是不良内存管理的好理由。单元测试的最佳实践是始终在
tearDown中释放在setUp中分配的内容，并在退出该方法之前处理该方法中分配的内存。我倾向于在单元测试中比在普通代码中更多地自动释放，因为它通常更简单。因为每个测试方法都在封闭测试类的单独实例中运行，所以设置/拆卸开销将主导自动释放池的任何惩罚。I'd say it's still important, yes, but not as critical as finding leaks in your actual code. Leaky unit tests can chew up more memory, especially if you choose not to release anything. Also, if you run your unit tests in Instruments to look for leaks (I sometimes do this, since I'm testing a framework rather than a normal app) leaky unit tests can distract from the actual leaks you're trying to find.
Sample code may be quick-n-dirty, but that's never good rationale for poor memory management. Best practice for unit tests is to always release in
tearDownwhat you allocate insetUp, and take care of memory allocated in a method before exiting that method. I tend to autorelease more in unit tests than in normal code, since it's often simpler. Because each test method is run in a separate instance of the enclosing test class, the setup/teardown overhead will dominate any penalty from autorelease pools.