iOS тесты / спецификации TDD / BDD и интеграционное и приемочное тестирование

Какие технологии лучше всего использовать для ориентированной на поведение разработки на iPhone? И какие проекты с открытым исходным кодом демонстрируют правильное использование этих технологий? Вот несколько вариантов, которые я нашел:

Модульное тестирование

Test :: Unit Style

1. OCUnit / SenTestingKit, как описано в Руководстве по разработке для iOS: приложения для модульного тестирования и другие ссылки на OCUnit .
   • Примеры: iPhoneUnitTests , Three20
2. ПОЙМАТЬ
3. GHUnit
4. Google Toolbox для Mac: модульное тестирование iPhone

RSpec Style

1. Киви (который также идет с насмешками и ожиданиями)
2. кедр
3. Жасмин с UI Automation, как показано в ловких спецификациях iOS-Acceptance-Testing

Приемочное тестирование

Селен Стиль

1. UI Automation (работает на устройстве)

   • Руководство по приборам автоматизации пользовательского интерфейса
   • Справочная документация по UI Automation
   • Tuneup JS - классная библиотека для использования с UIAutomation.

   • Захват действий пользовательского интерфейса в сценарии автоматизации

     Можно использовать Cucumber (написанный на JavaScript) для автоматизации пользовательского интерфейса. Это был бы отличный проект с открытым исходным кодом. Затем мы могли бы написать Gherkin для запуска тестирования автоматизации пользовательского интерфейса. А пока я просто напишу корнишон в качестве комментариев.

   ОБНОВЛЕНИЕ: Zucchini Framework, кажется, сочетает в себе Cucumber & UI Automation! :)

   Старые сообщения в блоге:

   • Учебник по автоматизации пользовательского интерфейса Алекса Воллмера
   • Учебное пособие по автоматизации пользовательского интерфейса O'Reilly
   • Учебник по автоматизации пользовательского интерфейса Ади Саксены

2. UISpec с UISpecRunner

   • UISpec является открытым исходным кодом в Google Code .
   • UISpec имеет исчерпывающую документацию .

3. FoneMonkey

Огуречный стиль

1. Фрэнк и iCuke (по мотивам встречи с огурцом и iPhone )

   • Группа Google Frank имеет гораздо большую активность, чем группа Google iCuke .
   • Фрэнк работает как на устройстве, так и на симуляторе, а iCuke - только на симуляторе.
   • У Фрэнка, кажется, есть более полный набор определений шагов, чем определения шагов iCuke . И у Фрэнка также есть сборник определений шагов в их вики .
   • Я предложил объединить iCuke & Frank (аналогично объединению Merb & Rails), поскольку у них одна общая цель: огурец для iOS.

2. KIF (сохранить функциональность) по квадратам

3. Zucchini Framework использует синтаксис Cucumber для написания тестов и CoffeeScript для определения шагов.

дополнения

• OCMock для насмешек
• OCHamcrest и / или Expecta для ожиданий

Вывод

Ну, очевидно, нет правильного ответа на этот вопрос, но вот что я выбрал в настоящее время:

Для модульного тестирования я использовал OCUnit / SenTestingKit в XCode 4. Это просто и надежно . Но я предпочитаю язык BDD, а не TDD ( почему RSpec лучше, чем Test :: Unit ?), Потому что наши слова создают наш мир. Так что теперь я использую Kiwi с ARC и дополнением / автозавершением кода Kiwi . Я предпочитаю киви, а не кедр, потому что он построен на основе OCUnit и поставляется с мэтчерами и заглушками в стиле RSpec. ОБНОВЛЕНИЕ: я теперь смотрю на OCMock, потому что, в настоящее время, Kiwi не поддерживает оштукатуренные объекты со свободным мостом .

Для приемочного тестирования я использую UI Automation, потому что это круто. Это позволяет вам записывать каждый тест, делая автоматическое написание тестов. Кроме того, Apple развивает его, и поэтому у него многообещающее будущее. Он также работает на устройстве и от Instruments, что позволяет использовать другие интересные функции, такие как отображение утечек памяти. К сожалению, с UI Automation я не знаю, как запускать код Objective-C, но с Frank & iCuke вы можете. Итак, я просто протестирую низкоуровневый Objective-C с помощью модульных тестов или создам UIButtons только для TESTконфигурации сборки , которая при нажатии запускает код Objective-C.

Какие решения вы используете?

Смежные вопросы

• Есть ли решение BDD, которое в настоящее время хорошо работает с iOS4 и Xcode4?
• SenTestingKit (интегрированный с XCode) против GHUnit на XCode 4 для модульного тестирования?
• Тестирование асинхронного кода на iOS с помощью OCunit
• SenTestingKit в Xcode 4: асинхронное тестирование?
• Как работает модульное тестирование на iPhone?

ТЛ; др

В Pivotal мы написали Cedar, потому что мы используем и любим Rspec в наших проектах Ruby. Cedar не предназначен для замены или конкуренции с OCUnit; Он предназначен для того, чтобы предоставить возможность тестирования в стиле BDD в Objective C, так же как Rspec впервые провёл тестирование в стиле BDD в Ruby, но не устранил Test :: Unit. Выбор одного или другого - в значительной степени вопрос стилевых предпочтений.

В некоторых случаях мы разработали Cedar для преодоления некоторых недостатков в том, как OCUnit работает для нас. В частности, мы хотели иметь возможность использовать отладчик в тестах, запускать тесты из командной строки и в сборках CI и получать полезный текстовый вывод результатов тестов. Эти вещи могут быть более или менее полезными для вас.

Длинный ответ

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

Соображения стиля выходят за рамки того, какую технологию или язык вы используете. Модульное тестирование в стиле xUnit существует гораздо дольше, чем тестирование в стиле BDD, но последнее быстро завоевало популярность, в основном благодаря Rspec.

Основным преимуществом тестирования в стиле xUnit является его простота и широкое применение (среди разработчиков, которые пишут модульные тесты); почти на любом языке, на котором вы могли бы написать код, есть фреймворк в стиле xUnit.

Фреймворки в стиле BDD, как правило, имеют два основных различия по сравнению со стилем xUnit: как вы структурируете тест (или спецификации) и синтаксис для написания ваших утверждений. Для меня структурная разница является основным отличием. Тесты xUnit являются одномерными, с одним методом setUp для всех тестов в данном классе тестов. Однако классы, которые мы тестируем, не являются одномерными; нам часто нужно тестировать действия в нескольких разных, потенциально противоречивых контекстах. Например, рассмотрим простой класс ShoppingCart с методом addItem: (для целей этого ответа я буду использовать синтаксис Objective C). Поведение этого метода может отличаться, когда корзина пуста по сравнению с тем, когда корзина содержит другие предметы; может отличаться, если пользователь ввел код скидки; может отличаться, если указанный элемент может быть отправлены выбранным способом доставки; и т. д. Поскольку эти возможные условия пересекаются друг с другом, вы получаете геометрически растущее число возможных контекстов; в тестировании в стиле xUnit это часто приводит к множеству методов с именами, такими как testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies. Структура фреймворков в стиле BDD позволяет вам организовывать эти условия индивидуально, что, на мой взгляд, облегчает обеспечение охвата всех случаев, а также облегчает поиск, изменение или добавление отдельных условий. Например, используя синтаксис Cedar, приведенный выше метод будет выглядеть следующим образом: в тестировании в стиле xUnit это часто приводит к множеству методов с именами, такими как testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies. Структура фреймворков в стиле BDD позволяет вам организовывать эти условия индивидуально, что, на мой взгляд, облегчает обеспечение охвата всех случаев, а также облегчает поиск, изменение или добавление отдельных условий. Например, используя синтаксис Cedar, приведенный выше метод будет выглядеть следующим образом: в тестировании в стиле xUnit это часто приводит к множеству методов с именами, такими как testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies. Структура фреймворков в стиле BDD позволяет вам организовывать эти условия индивидуально, что, на мой взгляд, облегчает обеспечение охвата всех случаев, а также облегчает поиск, изменение или добавление отдельных условий. Например, используя синтаксис Cedar, приведенный выше метод будет выглядеть следующим образом:

describe(@"ShoppingCart", ^{
    describe(@"addItem:", ^{
        describe(@"when the cart is empty", ^{
            describe(@"with no discount code", ^{
                describe(@"when the shipping method applies to the item", ^{
                    it(@"should add the item to the cart", ^{
                        ...
                    });

                    it(@"should add the full price of the item to the overall price", ^{
                        ...
                    });
                });

                describe(@"when the shipping method does not apply to the item", ^{
                    ...
                });
            });

            describe(@"with a discount code", ^{
                ...
            });
        });

        describe(@"when the cart contains other items, ^{
            ...
        });
    });
});

В некоторых случаях вы найдете контексты, которые содержат те же наборы утверждений, которые вы можете СУХОЙ, используя общие примеры контекстов.

Второе основное отличие между фреймворками в стиле BDD и фреймами в стиле xUnit, синтаксис утверждений (или совпадений), просто делает стиль спецификаций несколько приятнее; некоторым это действительно нравится, другим нет.

Это приводит к вопросу о простоте использования. В этом случае каждая структура имеет свои плюсы и минусы:

• OCUnit существует намного дольше, чем Cedar, и интегрируется непосредственно в Xcode. Это означает, что сделать новую цель тестирования просто, и, в большинстве случаев, запуск и запуск тестов "просто работает". С другой стороны, мы обнаружили, что в некоторых случаях, например, при работе на устройстве iOS, заставить работать тесты OCUnit практически невозможно. Настройка спецификаций Cedar требует больше работы, чем тесты OCUnit, поскольку вы сами получаете библиотеку и ссылаетесь на нее (никогда не бывает тривиальной задачей в XCode). Мы работаем над упрощением настройки, и любые предложения приветствуются.

• OCUnit запускает тесты как часть сборки. Это означает, что вам не нужно запускать исполняемый файл для запуска ваших тестов; если какие-либо тесты не пройдены, ваша сборка будет неудачной. Это делает процесс запуска тестов на один шаг проще, и вывод теста напрямую попадает в окно вывода вашей сборки, что облегчает его просмотр. Мы решили встроить спецификации Cedar в исполняемый файл, который вы запускаете отдельно по нескольким причинам:

  • Мы хотели иметь возможность использовать отладчик. Вы запускаете спецификации Cedar точно так же, как любой другой исполняемый файл, поэтому вы можете использовать отладчик таким же образом.
  • Мы хотели, чтобы в тестах было легко войти в консоль. Вы можете использовать NSLog () в тестах OCUnit, но вывод идет в окно сборки, где вам нужно развернуть шаг сборки, чтобы прочитать его.
  • Мы хотели, чтобы отчет о тестировании был легко читаем как в командной строке, так и в Xcode. Результаты OCUnit хорошо отображаются в окне сборки в Xcode, но сборка из командной строки (или как часть процесса CI) приводит к тому, что результаты теста смешиваются с большим количеством других результатов сборки. С раздельными фазами сборки и запуска Cedar разделяет выходные данные, поэтому их легко найти. Тестовый кедр по умолчанию копирует стандартный стиль печати "." для каждой передаваемой спецификации «F» для ошибочной спецификации и т. д. Cedar также имеет возможность использовать настраиваемые объекты-репортеры, так что вы можете получить результаты, полученные любым способом, без особых усилий.

• OCUnit является официальной платформой модульного тестирования для Objective C и поддерживается Apple. У Apple практически неограниченные ресурсы, поэтому, если они захотят что-то сделать, это будет сделано. И, в конце концов, это песочница Apple, в которую мы играем. Однако оборотная сторона этой монеты заключается в том, что Apple получает порядка баджиллиона запросов на поддержку и отчетов об ошибках каждый день. Они замечательно справляются со всеми, но могут не справиться с проблемами, о которых вы сообщаете немедленно или вообще. Cedar намного новее и менее выпечен, чем OCUnit, но если у вас есть вопросы, проблемы или предложения, отправьте сообщение в список рассылки Cedar (cedar-discuss@googlegroups.com), и мы сделаем все возможное, чтобы помочь вам. Кроме того, не стесняйтесь раскошелиться на код из Github (github.com/pivotal/cedar) и добавить то, что, по вашему мнению, отсутствует.

• Выполнение тестов OCUnit на устройствах iOS может быть затруднено. Честно говоря, я не пробовал это в течение достаточно долгого времени, так что, возможно, стало легче, но в прошлый раз я просто не мог заставить OCUnit-тесты работать с какой-либо функциональностью UIKit. Когда мы писали Cedar, мы убедились, что можем тестировать UIKit-зависимый код как на симуляторе, так и на устройствах.

Наконец, мы написали Cedar для модульного тестирования, что означает, что он не совсем сопоставим с такими проектами, как UISpec. Прошло довольно много времени с тех пор, как я пытался использовать UISpec, но я понял, что он сосредоточен в основном на программном управлении пользовательским интерфейсом на устройстве iOS. Мы специально решили не пытаться заставить Cedar поддерживать эти типы спецификаций, поскольку Apple (в то время) собиралась анонсировать UIAutomation.

Я собираюсь бросить Фрэнка в тестовый прием. Это довольно новое дополнение, но оно отлично сработало для меня. Кроме того, над ним активно ведутся работы, в отличие от icuke и других.

Для разработки через тестирование мне нравится использовать GHUnit , его легко настроить, и он отлично подходит для отладки.

Отличный список!

Я нашел другое интересное решение для тестирования пользовательского интерфейса приложений iOS.

Каркас цуккини

Это основано на UIAutomation. Каркас позволяет писать сценарии, ориентированные на экран, в стиле огурца. Сценарии могут быть выполнены в симуляторе и на устройстве с консоли (это дружественный к CI).

Утверждения основаны на скриншотах. Звучит негибко, но вы получите хороший HTML-отчет с выделенным сравнением экрана и можете предоставить маски, которые определяют области, которые вы хотите получить с точностью до пикселя.

Каждый экран должен быть описан, CoffeScriptа сам инструмент написан на ruby. Это своего рода кошмар полиглотта, но инструмент обеспечивает хорошую абстракцию для UIAutomationописания экранов, и когда он описан, им можно управлять даже для специалиста по обеспечению качества.

Я бы выбрал iCuke для приемочных испытаний и Cedar для юнит-тестов. UIAutomation - это шаг в правильном направлении для Apple, но инструментам нужна лучшая поддержка для непрерывной интеграции; например, автоматический запуск тестов UIAutomation с помощью инструментов в настоящее время невозможен.

GHUnit хорош для юнит-тестов; для интеграционных тестов я с некоторым успехом использовал UISpec (github fork здесь: https://github.com/drync/UISpec ), но я с нетерпением жду возможности попробовать iCuke, так как он обещает быть легкой установкой, и вы можете используйте рельсы для проверки качества, такие как RSpec и Cucumber.

В настоящее время я использую Specta для настройки, подобной rspec, и ее партнер (как уже упоминалось выше), ожидающий, что имеет множество потрясающих вариантов соответствия.

Мне действительно нравится OCDSpec2, но я предвзят, я написал OCDSpec и помогаю второму.

Это очень быстро даже на iOS, отчасти потому, что он построен с нуля, а не помещается поверх OCUnit. Он также имеет синтаксис RSpec / Jasmine.

https://github.com/ericmeyer/ocdspec2