Тестирование iOS-приложений

[Agent_Smith]

Отличная статья!

[1101_debian]

Спасибо, я старался.

[Tiboro]

Спасибо, полезная статья.

[egormerkushev]

Интересно, когда я доберусь до использования этих штук…

[1101_debian]

Просто попробуйте, и уже будет не оторвать ;-)

[ara89]

Спасибо, мне последнее время не хватало подобного руководства.

[1101_debian]

Calabash, кстати, есть и под Android.

[TAURUSiv43]

Можете описать почему Вы выбрали не стандартные механизмы тестирования 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>

[1101_debian]

UIAutomation — когда-то «пробовал».
Что не понравилось:

1. Нужно писать тесты на Javascript.
2. Для запуска тестов нужно открывть какое-то «левое» приложение, что очень неудобно если использовать CI (continuous integration), прийдется писать хитрый скрипт на AppleScript, и я не до конца уверен что это возможно.
3. И самый главный, который даже не позволил написать простейший тест: приложение должно быть подписано. Подписать приложение не проблема, но зачем я должен делать это для простого обучения?..

Ну а плюсов я не нашел.
Стандартный фрэймворк для unit-тестов — пробовал Kiwi на его основе.
Минусы:

1. Точки останова в тест-кейсах не работают.
2. Для тестирования CoreData пришлось писать массу лишнего кода обернутого в #ifdef (хотя может я что-то не так сделал) для того чтобы создать PersistentStorage, часа 4 убил на все это дело.
3. Опять таки не знаю как это будет работать на CI.

Плюсы: работает почти «из коробки»

[1101_debian]

К тому же я параллельно пишу на RoR, потому RSpec- и Cucumber-style как-то больше по душе.
Но это все субъективно, кому что нравится.

[TAURUSiv43]

Ну давайте для начала про SenTestingKit — я оберток на него не использовал, не знаю, что такое Kiwi и какие с ним проблемы, но код из Вашего примера выглядит так:

<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).

[1101_debian]

Я не пробовал SenTestingKit, но я попробовал использовать Cedar и мне это понравилось. Проблема с CoreData очень сильно оттолкнула от использования стандартных тестов. А писать UI-тесты на Javascript как-то не хочется.

Когда я пишу тесты для iOS на Cucumber, то я не учу инструмент_только_для_iOS, а я изучаю универсальный инструмент, он позволяет мне писать теже тесты и для Rails приложений, и если я вдруг буду писать под Android, то мне не придется изучать какой-нибудь специфичный для этой ОС фрэймворк.

Говорю ж, все это субъективно, я описал то чем я тестирую, и я ни в окем случае не настаиваю на том чтобы все начали использовать только эти средства :)

[Infernal]

Если Cedar заменить на Kiwi то получим все те же плюшки + более декларативный синтаксис и библотеку для мокинга (не нужно тянуть за собой OCMock). Еще могу сказать, что при написании тестов в RSpec-стиле новичкам гораздо проще понять, что и как надо тестировать.

[Pilot34]

Брейкпоинты как-то почему-то через раз работали, когда я последний раз мучил SenTestKit.

В какой-то презентации про GHUnit (другой движок для тестов) видел аргумент «не нужно иметь PHD, чтобы дебажить тесты» :)

А UIAutomation вы в итоге где-нибудь используете? Проблема с UI-тестами, что хорошо бы их писать тестировщику, т.к. девелоперу обычно некогда и лень. Но нужно серьезно уметь программировать, чтобы их написать. Cucumber пытается это исправить, но ИМХО не до конца.