Comments 14
Отличная статья!
+1
Спасибо, полезная статья.
+1
Интересно, когда я доберусь до использования этих штук…
+1
Спасибо, мне последнее время не хватало подобного руководства.
0
Calabash, кстати, есть и под Android.
+1
Можете описать почему Вы выбрали не стандартные механизмы тестирования iOS программ из коробки (SenTestKit и Automation)?
Пример теста:
Пример теста:
<hh user=implementation> iOSControlsTests
- (void)setUp
{
[super setUp];
// Set-up code here.
}
- (void)tearDown
{
// Tear-down code here.
[super tearDown];
}
- (void)testExample
{
STFail(@"Unit tests are not implemented yet in iOSControlsTests");
NSString* string = nil;
STAssertNil(string, @"String should be nil");
}
<hh user=end>
+2
UIAutomation — когда-то «пробовал».
Что не понравилось:
Ну а плюсов я не нашел.
Стандартный фрэймворк для unit-тестов — пробовал Kiwi на его основе.
Минусы:
Плюсы: работает почти «из коробки»
Что не понравилось:
- Нужно писать тесты на Javascript.
- Для запуска тестов нужно открывть какое-то «левое» приложение, что очень неудобно если использовать CI (continuous integration), прийдется писать хитрый скрипт на AppleScript, и я не до конца уверен что это возможно.
- И самый главный, который даже не позволил написать простейший тест: приложение должно быть подписано. Подписать приложение не проблема, но зачем я должен делать это для простого обучения?..
Ну а плюсов я не нашел.
Стандартный фрэймворк для unit-тестов — пробовал Kiwi на его основе.
Минусы:
- Точки останова в тест-кейсах не работают.
- Для тестирования CoreData пришлось писать массу лишнего кода обернутого в #ifdef (хотя может я что-то не так сделал) для того чтобы создать PersistentStorage, часа 4 убил на все это дело.
- Опять таки не знаю как это будет работать на CI.
Плюсы: работает почти «из коробки»
+1
К тому же я параллельно пишу на RoR, потому RSpec- и Cucumber-style как-то больше по душе.
Но это все субъективно, кому что нравится.
Но это все субъективно, кому что нравится.
+1
Ну давайте для начала про SenTestingKit — я оберток на него не использовал, не знаю, что такое Kiwi и какие с ним проблемы, но код из Вашего примера выглядит так:
Плюсы следующие:
1. Тесты на языке основной программы
2. Поддержка Xcode — нажимаем cmd + U и видем красивый пабл с инфой прошли тесты или нет
3. Очень удобно дебажиться, все брейкпоинты работают
4. Не требует сторонних библиотек и не добавляет ничего в код программы, наоборот в тестовую версию программы ложиться дополнительный бандл
Хочу заметить, что все это работает как на симуляторе так и на устройстве (я значит сертификат не нужен), проблем с обращением к локальным файлам программы (тот же PersistantStore) нету.
Про Automation — так же работает как с симулятором так и с девайсом, «родная интеграция» — видит все контролы (полностью повторяет иерархию контролов), в том числе клавиатуру, можно записывать действия для выполнения, а можно писать скрипты.
Единственное — интеграция с CI действительно не прозрачная, хотя тот же Automation полностью поддерживает запуск из консоли (как часть Instruments).
<hh user=implementation> CalculationManagerTests
- (void)testSharedInstance
{
STAssertNotNil([CalculationManager sharedInstance], @"sharedInstance should not return nil");
}
- (void)testMathOperations
{
CalculationManager* manager = [CalculationManager sharedInstance];
NSInteger left = 5;
NSInteger right = 37;
NSInteger etalonResult = 42;
NSInteger realResult = [manager add:left with:right];
STAssertEquals(etalonResult, realResult, @"addition should be correct");
left = 14;
right = 12;
etalonResult = 2;
realResult = [manager subtract:right from:left];
STAssertEquals(etalonResult, realResult, @"subtract should be correct");
}
<hh user=end>
Плюсы следующие:
1. Тесты на языке основной программы
2. Поддержка Xcode — нажимаем cmd + U и видем красивый пабл с инфой прошли тесты или нет
3. Очень удобно дебажиться, все брейкпоинты работают
4. Не требует сторонних библиотек и не добавляет ничего в код программы, наоборот в тестовую версию программы ложиться дополнительный бандл
Хочу заметить, что все это работает как на симуляторе так и на устройстве (я значит сертификат не нужен), проблем с обращением к локальным файлам программы (тот же PersistantStore) нету.
Про Automation — так же работает как с симулятором так и с девайсом, «родная интеграция» — видит все контролы (полностью повторяет иерархию контролов), в том числе клавиатуру, можно записывать действия для выполнения, а можно писать скрипты.
Единственное — интеграция с CI действительно не прозрачная, хотя тот же Automation полностью поддерживает запуск из консоли (как часть Instruments).
+2
Я не пробовал SenTestingKit, но я попробовал использовать Cedar и мне это понравилось. Проблема с CoreData очень сильно оттолкнула от использования стандартных тестов. А писать UI-тесты на Javascript как-то не хочется.
Когда я пишу тесты для iOS на Cucumber, то я не учу инструмент_только_для_iOS, а я изучаю универсальный инструмент, он позволяет мне писать теже тесты и для Rails приложений, и если я вдруг буду писать под Android, то мне не придется изучать какой-нибудь специфичный для этой ОС фрэймворк.
Говорю ж, все это субъективно, я описал то чем я тестирую, и я ни в окем случае не настаиваю на том чтобы все начали использовать только эти средства :)
Когда я пишу тесты для iOS на Cucumber, то я не учу инструмент_только_для_iOS, а я изучаю универсальный инструмент, он позволяет мне писать теже тесты и для Rails приложений, и если я вдруг буду писать под Android, то мне не придется изучать какой-нибудь специфичный для этой ОС фрэймворк.
Говорю ж, все это субъективно, я описал то чем я тестирую, и я ни в окем случае не настаиваю на том чтобы все начали использовать только эти средства :)
+1
Если Cedar заменить на Kiwi то получим все те же плюшки + более декларативный синтаксис и библотеку для мокинга (не нужно тянуть за собой OCMock). Еще могу сказать, что при написании тестов в RSpec-стиле новичкам гораздо проще понять, что и как надо тестировать.
+1
Брейкпоинты как-то почему-то через раз работали, когда я последний раз мучил SenTestKit.
В какой-то презентации про GHUnit (другой движок для тестов) видел аргумент «не нужно иметь PHD, чтобы дебажить тесты» :)
А UIAutomation вы в итоге где-нибудь используете? Проблема с UI-тестами, что хорошо бы их писать тестировщику, т.к. девелоперу обычно некогда и лень. Но нужно серьезно уметь программировать, чтобы их написать. Cucumber пытается это исправить, но ИМХО не до конца.
В какой-то презентации про GHUnit (другой движок для тестов) видел аргумент «не нужно иметь PHD, чтобы дебажить тесты» :)
А UIAutomation вы в итоге где-нибудь используете? Проблема с UI-тестами, что хорошо бы их писать тестировщику, т.к. девелоперу обычно некогда и лень. Но нужно серьезно уметь программировать, чтобы их написать. Cucumber пытается это исправить, но ИМХО не до конца.
0
Sign up to leave a comment.
Тестирование iOS-приложений