it-swarm.com.ru

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

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


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

Test :: Unit Стиль

  1. OCUnit/SenTestingKit как описано в Руководство по разработке iOS: приложения для модульного тестирования & other ссылки на OCUnit .
  2. CATCH
  3. GHUnit
  4. Google Toolbox для Mac: модульное тестирование iPhone

RSpec Стиль

  1. Киви (что также сопровождается насмешками и ожиданиями)
  2. Cedar
  3. Жасмин с I Automation как показано в ловкие 'спецификации iOS-Acceptance-Testing

приемочные испытания

Селен Стиль

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

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

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

  2. ISpec с ISpecRunner

  3. FoneMonkey

огурец стиль

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

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

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

Дополнения

Заключение

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

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

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

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

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

229
ma11hew28

тЛ; др

В 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, приведенный выше метод будет выглядеть следующим образом:

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, ^{
            ...
        });
    });
});

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

Второе основное отличие между фреймворками в стиле 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 ([email protected]), и мы сделаем все возможное, чтобы помочь вам. Кроме того, не стесняйтесь раскошелиться на код из Github (github.com/pivotal/cedar) и добавить то, что, по вашему мнению, отсутствует. Мы делаем наши тестовые фреймворки с открытым исходным кодом по определенной причине.

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

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

53
Adam Milligan

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

8
raidfive

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

5
Richard J. Ross III

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

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

Zucchini Framework

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

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

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

4
mzaks

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

2
SamCee

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

1
Keith Smiley

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

1
Rob

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

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

https://github.com/ericmeyer/ocdspec2

0
Eric Smith