如何确保调用 OCUnit 测试套件tearDown?

发布于 2024-11-04 06:57:44 字数 283 浏览 6 评论 0原文

在我们的 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 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

梦幻的味道 2024-11-11 06:57:44

我建议您在测试套件中添加一个布尔 ivar,当一切设置正确时,它会在 setUp 中设置。然后将 NSAssert 替换为设置此变量,例如。由 STAssert 标记...以防出现任何问题,从而导致您的测试失败。

在每个测试用例中,您然后在执行检查之前检查此 ivar 是否为 true,例如,通过使用类似以下内容:

-(void)setUp {
  // Perform the setup of the testbed and setting testBedStable accordingly
  STAssertTrue(testBedStable, @"Failed to setup test environment";
}

-(void)testSomething {
  if(testBedStable) {
    // Perform tests
  }
  else
    STFail(@"Unable to perform test case");
}

此方法将确保始终调用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:

-(void)setUp {
  // Perform the setup of the testbed and setting testBedStable accordingly
  STAssertTrue(testBedStable, @"Failed to setup test environment";
}

-(void)testSomething {
  if(testBedStable) {
    // Perform tests
  }
  else
    STFail(@"Unable to perform test case");
}

This method will ensure tearDown is always called and you can clean up accordingly.

挽袖吟 2024-11-11 06:57:44

是的,不要使用 NSAssert。相反:

  • 将数据库设置放入单独的辅助方法中。
  • 设置实例变量以指示已成功设置的内容。
  • STFail 对于任何未成功设置的内容。
  • 让每个测试调用适当的帮助器方法。
  • -tearDown中,检查实例变量以查看需要清理的内容。

示例:

@interface DatabaseTest : SenTestCase
{
    BOOL removeTestDataInTearDown;
}

- (void)addTestDataToDatabase
{
    BOOL success;
    // Attempt to add data to database. Set success according to results.
    if (!success)
        STFail(@"Unable to add test data to database", nil);
    removeTestDataInTearDown = YES;
}

- (void)removeTestDataFromDatabase
{
    // Remove data from database.
}

- (void)tearDown
{
    if (removeTestDataInTearDown)
        [self removeTestDataFromDatabase];

    [super tearDown];
}

- (void)testSomething
{
    [self addTestDataToDatabase];
    // Execute test using data.
}

请注意,即使这样也有可能在数据库中留下痕迹,这使得此类测试变得脆弱。因此,您可以使用一组不同的测试来补充此类测试,这些测试使用模拟对象代替真实的数据库调用。

Right, don't use NSAssert. Instead:

  • Pull database setup into separate helper methods.
  • Set instance variables to indicate what was successfully set up.
  • STFail on anything that isn't successfully set up.
  • Have each test call the appropriate helper methods.
  • In -tearDown, check the instance variables to see what needs to be cleaned up.

Example:

@interface DatabaseTest : SenTestCase
{
    BOOL removeTestDataInTearDown;
}

- (void)addTestDataToDatabase
{
    BOOL success;
    // Attempt to add data to database. Set success according to results.
    if (!success)
        STFail(@"Unable to add test data to database", nil);
    removeTestDataInTearDown = YES;
}

- (void)removeTestDataFromDatabase
{
    // Remove data from database.
}

- (void)tearDown
{
    if (removeTestDataInTearDown)
        [self removeTestDataFromDatabase];

    [super tearDown];
}

- (void)testSomething
{
    [self addTestDataToDatabase];
    // Execute test using data.
}

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文