Модульное тестирование и TDD, OCUnit против Google Tool Box - PullRequest
Новая
       22

Модульное тестирование и TDD, OCUnit против Google Tool Box

10 голосов
/ 14 декабря 2009

Я пытаюсь выбрать между OCUnit и Google Tool Box, есть ли у вас какие-либо предпочтения, порекомендуете один или другой, почему? Мне было бы очень интересно услышать о вашем опыте с любым из 2.

Основная проблема, которую я имею с ними обоими, - это управление сбоями в тестируемых методах (например: BAD ACCESS) Никто из них не смог мне сказать, в каком классе произошла авария !!!

С помощью Google Tool Box я могу видеть, какой набор тестов был запущен, но не тестовый набор (как вы должны поступить, когда ваш набор тестов имеет 50 тестовых наборов?)

С помощью OCUnit я могу хотя бы посмотреть, какой тестовый набор в каком наборе тестов вызвал сбой.

Вот сообщение, которое я имею с GTB: 

Executed 0 tests, with 0 failures (0 unexpected) in 0.000 (0.000) seconds

Test Suite 'LogicTests' started at 2009-12-14 18:03:15 +0100

 /Users/admin/Documents/Tests/GTBTest/RunIPhoneUnitTest.sh: line 122:   688    Segmentation fault      "$TARGET_BUILD_DIR/$EXECUTABLE_PATH" -RegisterForSystemEvents

 Command /bin/sh failed with exit code 139

Я вижу, что именно тестовый набор 'LogicTests' вызвал сбой, но это все.

С OCunit вот сообщение для той же ошибки: 

Test Suite 'LogicTests' started at 2009-12-14 17:51:26 +0100
Test Case '-[LogicTests testFail]' started.
/Developer/Tools/RunPlatformUnitTests.include: line 415:   536 Segmentation fault      "${THIN_TEST_RIG}" "${OTHER_TEST_FLAGS}" "${TEST_BUNDLE_PATH}"

По крайней мере, с помощью OCUnit я могу отследить, какой тестовый пример выполнялся, и в конечном итоге отладить его (но это может занять очень много времени без информации о классе и номере строки ...)

Как вы справляетесь с этими проблемами?

Заранее спасибо.

PS: вот как воспроизвести проблему, все очень просто:

Просто создайте класс с методом, который вылетает при его вызове (что происходит постоянно, когда вы выполняете TDD): 

- (void) crashMethod {
 NSMutableArray *crashArray;
 [crashArray addObject:[NSObject new]];
}

И затем создайте тестовый пример, который вызывает эти методы: 

- (void) testFail {
    ClassToTest *test = [[ClassToTest alloc] init];
 [test crashMethod];
 [test release];
 }

Заранее спасибо, Винсент

Ответы [ 2 ]

3 голосов
/ 15 декабря 2009

Я думаю, я все равно пойду с GTB ..

В xCode 3.2 ошибки и предупреждения OCUnit не отображаются внутри кода. Кажется, это известная проблема: л http://osdir.com/ml/xcode-users/2009-10/msg00216.html

С GTB работает нормально. Я не могу в это поверить, но кажется, что GTB лучше интегрирован с более новыми версиями xCode, чем OCUnit ....

Отладка модульных тестов не требует ничего, она отлично работает с самого начала. (с xCode вам нужно несколько настроек: http://chanson.livejournal.com/119578.html

С GTB вы можете запускать свои тесты на устройстве, и у вас есть инструменты для тестирования пользовательского интерфейса (кажется, вы можете создать ложную иерархию UIView, а затем сравнить ее с тем, что у вас есть во время выполнения). Я скептически отношусь к автоматическому тестированию пользовательского интерфейса (дорого и сложно в обслуживании), но это хорошая функция!

http://code.google.com/p/google-toolbox-for-mac/wiki/CodeVerificationAndUnitTesting

0 голосов
/ 01 июля 2010

Кстати, Google Toolbox теперь печатает сообщения о начале тестового случая, если кому-то интересно; -)

...