Мы подумали об использовании Behat для наших приемочных тестов после PHP.TO.START в Турине; Behat является PHP-версией Cucumber. Через некоторое время я повторно использовал объекты, которые наши первые сквозные тесты PHPUnit вызывали для работы с системой, чтобы подготовить базовый FeatureContext, способный выполнять платеж с Onebip; несколько недель спустя у нас были готовые спецификации для первых тестов в Испании.
Перемотка вперед на шесть месяцев
Теперь у нас есть более чем на час проверки спецификаций Behat на наших серверах интеграции, где четыре различных проекта развернуты рядом друг с другом. Мы приняли несколько мер для ускорения процесса (и с этим наши ежедневные развертывания):
- улучшение аппаратного обеспечения сервера и наших машин для разработки.
- экспериментально, запустите несколько процессов Behat параллельно.
Набор тестов имитирует более ста сценариев, каждый из которых идет от одной покупки до 3-4 недель, когда подписка продлевается. Когда вы моделируете эту большую работу, вы все время побеждаете на ручном тестировании; однако мы сопротивлялись, по крайней мере, на данный момент, переходу старых и более редких сценариев к ночной сборке, которая не мешает развертыванию.
Отзывы о ночной сборке очень медленные, потому что в среднем вы узнаете, не прошли ли вы тест через 12 часов.
Воспроизводимость
Мы начали со сценариев, похожих друг на друга:
Given I am in ES And I am a Vodafone user When I subscribe to ES_SOME_SERVICE Then I am billed 3.00 EUR And the merchant is notified with SUBSCRIPTION_ACTIVATED
и мы использовали их для интеграции различных компонентов распределенной системы, которой сегодня является Onebip. Разный код запускается в зависимости от страны и оператора мобильной связи, поскольку у каждого есть свой интерфейс для платежей, откуда мы берем деньги. Таким образом, есть большая ценность в повторении этих испытаний для всех новых развитых стран и связей.
Оттуда мы также перешли к сценариям взаимодействия с пользователем. Даже если у нас есть только одна страница, обращенная к пользователю (платежная), есть несколько возможных угловых случаев, которые вы можете захотеть протестировать сквозным образом:
Given I am in ES And I am a Vodafone user And I walked in on ES_SOME_SERVICE And I received a pin When I walk in again on the same service And I insert the previously received pin Then I am billed 3.00 EUR
Трудности
Нелегко получить стабильные комплексные тесты. Behat требует автоматизации, поскольку вы не можете поместить while () и сложный код в файлы объектов, но вы должны выполнить правильные условия ожидания вместо sleep () в течение фиксированного промежутка времени. Везде, где задействовано более одного компонента, мешает асинхронный API, требующий асинхронных утверждений.
Вот наиболее распространенные проблемы, с которыми мы столкнулись при выполнении наших исполняемых спецификаций:
- синхронизировать процессы cron , которые необходимо вызывать вручную и фильтровать, чтобы они действовали только на текущие тестовые объекты (такие как текущий номер телефона или пользовательская подписка). Вы должны отключить все запланированные в определенное время кроны и задания перед запуском пакета.
- Связанная проблема — это необходимые инвестиции для моделирования рабочего времени : внедрение часов в приложения, которые постоянно хранятся в коллекции MongoDB и которые можно перенести через API.
- Поддержание дисциплины между бэкдорами (запрос к базам данных различных интегрированных компонентов напрямую для быстрой реализации теста) и действия через API (более гибкие и позволяющие избежать несовместимых назад изменений в будущем, даже если это клиент, который мы полностью контролируем).
- Поддержание актуальности всех проектов и версий, идентичных производственным; Мы извлечем тесты Behat в отдельный проект, поскольку они фактически тестируют все приложение, а не одного конечного пользователя.
- Узнав проект, который сломал трубопровод! В последней ретроспективе мы поняли, что все проекты должны сходиться к фазе интеграции в CI, они больше не являются независимыми (но они могут быть развернуты независимо после этой фазы, по одному за раз).
Написание сценариев: как
Тем не менее, даже если они тяжелы для запуска (но не для обслуживания), вы хотите, чтобы сценарии тестировали одну вещь и имели одну, максимум две причины неудачи. Например, мы объединяем платежные и торговые уведомления о событии, поскольку они тесно связаны; но текстовые сообщения, полученные пользователем или политики повторных попыток, разделены в их собственных сценариях.
Вы все еще хотите устранить большую часть дублирования внутри сценариев. Тем не менее, вы не можете удалить дублирование путем извлечения методов из файла объектов, так как это совершенно другой стиль, чем тест xUnit. Тогда шаги можно легко разделить на сценарии, не делая их в одной батарее, а разделяя их; однако должны быть доступны даже такие большие шаги, как «Учитывая, что я подписан на две недели», с разумными значениями по умолчанию с их параметрами, такими как страна пользователя.
Этот выбор позволяет вам трансформироваться>
Given I am in IT And I am a Vodafone user And I subscribe to SERVICE_NAME And I am billed And 7 days have passed ...
в
Given I have been subscribed for 7 days ...
более точное представление о том, что действительно важно в начальных условиях.
Как говорят ребята из Etsy , ваша система должна быть настолько простой в использовании, чтобы бот мог в ней перемещаться. Для нас это было легко на уровне интерфейса, так как наша платежная страница имеет один или два клика в качестве основных действий; сложная часть заключалась в автоматизации внутренних взаимодействий с носителями.
Написание сценариев: кто
Мы все еще не на уровне написания сценариев напрямую с заказчиком. Сейчас мы вместе пишем историю пользователя, что является большим улучшением по сравнению с фазой «сбора требований», когда передается куча файлов Excel и неофициальных документов Word.
Когда мы находимся в одном офисе с этими внутренними клиентами, это становится намного проще, но это не всегда возможно. Поскольку клиенты почти никогда не посещают Agile-мероприятия и конференции (может быть, им следует), техническая команда несет ответственность за их поиск и начало совместной работы, которая является частью Манифеста. BDD делает возможным это сотрудничество, предлагая ряд примеров в качестве знаний, полученных в результате встречи технических и деловых людей, и это следующий шаг, который мы хотим сделать.