Как убедиться, что OCUnit test suite называется tearDown? - PullRequest
Новая
       11

Как убедиться, что OCUnit test suite называется tearDown?

1 голос
/ 02 мая 2011

В наших модульных тестах приложения для iPhone у нас есть один набор тестов, который содержит все классы тестовых случаев.В наборе setUp / tearDown пакета мы делаем общую настройку / удаление, которая создает / удаляет некоторые объекты в БД.В setUp мы используем NSAsserts, чтобы утверждать, что все прошло правильно.Проблема в том, что если что-то идет не так в setUp, NSAssert вызывает сбой, а tearDown не вызывается, оставляя БД не очищенной.

Каков наилучший способ убедиться, что tearDown всегда вызывается, поэтому БД всегдачистить?Может быть, не использовать NSAsserts?Но тогда как сказать инфраструктуре тестирования, чтобы она не запускала контрольные примеры?

Спасибо.

Ответы [ 2 ]

2 голосов
/ 10 мая 2011

Я предлагаю вам добавить логический ivar в ваш набор тестов, который устанавливается в setUp, когда все настроено правильно.NSAssert затем заменяется установкой этой переменной, например.помечено STAssert ... в случае, если что-то пойдет не так, что это приведет к сбою вашего теста.

В каждом тестовом примере вы проверяете, что этот ivar верен перед выполнением проверок, например, используя что-то вроде этого:

-(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 всегда вызывается, и вы можете очистить соответствующим образом.

1 голос
/ 03 мая 2011

Правильно, не используйте NSAssert.Вместо этого:

  • Объединить настройки базы данных в отдельные вспомогательные методы.
  • Установить переменные экземпляра, чтобы указать, что было успешно установлено.
  • STFail для всего, что не 't успешно настроен.
  • Пусть каждый тест вызывает соответствующие вспомогательные методы.
  • В -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.
}

Обратите внимание, что даже это может привести к потере данных в базе данных, что делает такие тесты хрупкими.Таким образом, вы можете дополнить такие тесты другим набором тестов, который использует фиктивные объекты вместо реальных вызовов базы данных.

...