【发布时间】：2009-11-23 18:30:42
【问题描述】：
我还应该在单元测试中释放对象吗？
我注意到在 Apple 的“iPhoneUnitTests”示例项目中，setup 方法中的对象是 [[object alloc] init]，但从未在单元测试的任何地方发布？
谢谢！
【问题讨论】：
标签： iphone objective-c cocoa unit-testing ocunit
【发布时间】：2009-11-23 18:30:42
【问题描述】：
我仍然会做适当的内存管理。
我觉得输入init 或retain 不输入release 太脏了。这是一个好习惯。
此外，正如 Epsilon Prime 在 cmets 中提到的，能够测试泄漏是很有用的。
【讨论】：
-
能够在代码的某个小节中查找漏洞仍然很重要。另外，如果您更改内存管理的行为，您将在单元测试而不是完成的项目中发现问题。
-
@Epsilon Prime：如果这是一个答案，我会赞成。好点子。
始终练习良好的内存管理是个好主意。它显然不会伤害你，即使它没有潜在的帮助。此外，更多地练习正确的内存管理（而不是说“它在这里不那么重要”）只会让你在重要的时候不太可能犯错误。
不要仅仅因为您看到不遵循最佳实践的某样示例代码而放弃最佳实践。我的猜测是，这样的示例代码可能不是由那些有很多经验的人编写的（因为这些人正在做更重要的工作），所以虽然示例代码可以展示它的意图，但它通常不是最好的东西检查与样本预期目的无关的问题（例如最佳编码实践）。
【讨论】：
-
是的，就像演示代码很少有完整的错误/异常处理写入其中。在生产代码中，错误/异常处理很容易是代码的一半，但您几乎从未在正式或非正式的教学示例中看到过这一点
两个测试套件都进行了适当的内存管理。
CalcTest 只是将变量分配给作为 AppDelegate 的一部分存在的对象，即它永远不会保留它们，因此它永远不会“拥有”它们。
CalculatorTest 释放它在 tearDown 中拥有的对象，因为它应该按照单元测试文档。
【讨论】：
我会说它仍然很重要，是的，但不如在您的实际代码中发现泄漏那么重要。泄漏的单元测试会消耗更多的内存，尤其是当您选择不释放任何东西时。此外，如果您在 Instruments 中运行单元测试以查找泄漏（我有时会这样做，因为我正在测试框架而不是普通应用程序）泄漏单元测试可能会分散您尝试查找的实际泄漏的注意力。
示例代码可能很快就很脏，但这绝不是糟糕的内存管理的好理由。单元测试的最佳实践是始终在tearDown 中释放您在setUp 中分配的内容，并在退出该方法之前处理该方法中分配的内存。我倾向于在单元测试中比在普通代码中更多地自动发布，因为它通常更简单。因为每个测试方法都在封闭测试类的单独实例中运行，所以设置/拆卸开销将支配自动释放池的任何惩罚。
【讨论】：