如何确保调用 OCUnit 测试套件tearDown?
在我们的 iPhone 应用程序单元测试中,我们有一个测试套件,其中包含所有测试用例类。在套件的 setUp/tearDown 中,我们进行常规设置/拆卸,在数据库中创建/删除一些实体。在 setup 中,我们使用 NSAsserts 来断言一切顺利。 问题是,如果 setUp 中出现问题,NSAssert 会导致崩溃,并且不会调用tearDown,从而导致数据库未被清理。
确保始终调用tearDown以使数据库始终干净的最佳方法是什么?也许不使用 NSAsserts?那么如何告诉测试框架不运行测试用例呢?
谢谢。
In our iPhone app unit tests we have one test suite which contains all test case classes. In the suite's setUp/tearDown we do general set up/tear down which creates/deletes some entities in DB. In setUp we use NSAsserts to asserts everything went right.
The problem is that if something goes wrong in setUp, NSAssert causes crash and tearDown is not being called, leaving the DB uncleaned.
What is the best way to make sure tearDown is always being called so the DB is always clean? Maybe not to use NSAsserts? But then how to tell the testing framework to not run test cases?
Thanks.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
我建议您在测试套件中添加一个布尔 ivar,当一切设置正确时,它会在 setUp 中设置。然后将 NSAssert 替换为设置此变量,例如。由 STAssert 标记...以防出现任何问题,从而导致您的测试失败。
在每个测试用例中,您然后在执行检查之前检查此 ivar 是否为 true,例如,通过使用类似以下内容:
此方法将确保始终调用tearDown,并且您可以相应地进行清理。
I'll suggest you add a boolean ivar to your test suite which is set in setUp when everything is setup correctly. The NSAssert is then replaced with setting this variable, eg. flagged by STAssert... in case anything goes wrong so it will cause your test to fail.
In each test case you then check that this ivar is true before performing the checks, e.g. by using something like this:
This method will ensure tearDown is always called and you can clean up accordingly.
是的,不要使用 NSAssert。相反:
STFail
对于任何未成功设置的内容。-tearDown
中,检查实例变量以查看需要清理的内容。示例:
请注意,即使这样也有可能在数据库中留下痕迹,这使得此类测试变得脆弱。因此,您可以使用一组不同的测试来补充此类测试,这些测试使用模拟对象代替真实的数据库调用。
Right, don't use NSAssert. Instead:
STFail
on anything that isn't successfully set up.-tearDown
, check the instance variables to see what needs to be cleaned up.Example:
Note that even this has the potential to leave cruft in the database, which makes such tests fragile. So you might complement such tests with a different set of tests that uses mock objects in place of real database calls.