PHP очень популярный язык программирования, но тестирование в нем, это скорее прерогатива экспертов, а не жизненная необходимость. Неужели это от того, что PHP-разработчики поголовно быдло-кодеры? Я считаю, что нет. Скорее всё от того, что системы тестирования порой излишне усложнены. А тесты, наоборот, должны были предельно просты: легко читаться, писаться, отлаживаться, и конечно же, быстро выполняться. Мое виденье того как это можно воплотить в PHP вылилось в проект под названием Codeception.

С ним тесты для ваших веб-приложений могут выглядеть так:

<?php
$I = new TestGuy($scenario);
$I->wantTo('create new blog post');
$I->amOnPage('/blog/posts');
$I->click('Create new post');
$I->fillField('Title','Codeception, a new way of testing!');
$I->fillField('Text','Codeception is new PHP full-stack testing framework.');
$I->click('Send');
$I->see('Congratulations, your post is successfully created!');

Согласитесь, такой тест понятен без дополнительных комментариев.
А теперь самое интересное: этот код без всяких изменений может быть выполнен как функциональный тест в фреймворках symfony, Symfony2,Zend Framework, а также в браузерном эмуляторе Goutte и даже через Selenium. Таким образом, вам предлагается единый интерфейс для написания функциональных тестов практически для любого сайта.

Сразу хочу сказать, что в статье я не буду описывать как надо работать с Data Provider-ом. Это можно найти и в документации и в многочисленных статьях в интернете.
Здесь я расскажу про шаблоны проектирования Domain Model, Singleton, Repository, про подход Behavior Driven Development (BDD) и как я их использовал в своей программе.

Шаблон Domain Model используется в тех случаях когда разработка ведется от предметной области, в таких случаях есть понятная предметная область и ее термины просто воплощаются в байтах.

Например, в моей программе предметная область состоит из данных расписания, заданного в виде нескольких будильников, для будильника можно задать дни недели и время, а также признак «будильник включен». Так же есть несколько алгоритмов, например получить будильник, который сработает следующим и дату и время его срабатывания. Поскольку будильник может дремать, получается что у одного будильника есть несколько срабатываний с разными действиями: первое срабатывание, дремание, и последнее дремание, когда кнопка дремать уже не доступна. Поэтому есть еще алгоритм поучения ближайшего абсолютного времени и действия.
Так же есть алгоритмы для создания нового будильника и редактирования/удаления существующих.

То есть в моей предметной области есть данные в виде нескольких будильников и несколько алгоритмов, которые реализуют логику предметной области.

Почему я вообще решил использовать этот шаблон проектирования. В альтернативу я бы мог сделать отдельный класс, который создает/редактирует будильники и сохраняет их в БД, а алгоритмы вычисления ближайшего будильника можно было сделать в другом классе.

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

Во-вторых, в таком случае, когда я тестирую модель я могу протестировать обычное поведение пользователя. Например создать будильник, задать ему расписание, проверить что модель выдает правильное следующее время, потом я добавляю новый будильник, а старый отключаю и проверяют что и на этот раз время следующего срабатывания правильное.

Такой подход называется Behavior Driven Development. Его достоинство в том, что я могу тестировать модель в терминах предметной области, то есть в модульных тестах я имитирую обычное поведение пользователя. Благодаря тому, что это реализовано через механизм модульных тестов, я перед каждым релизом могу эти тесты прогнать и быть уверенным, что моя программа программа нормально отрабатывает основные действия пользователя.

Если бы я использовал отдельный класс для редактирования/сохранения будильников и отдельный класс для вычисления ближайшего будильника, то я конечно бы протестировал их по отдельности, но не смог бы проверить их вместе и не смог бы проверить основные действия пользователя.

Тестирование стало неотъемлемой частью любой разработки программного продукта, будь то приложение под настольный компьютер, мобильное устройство или web. Уже никто не отрицает важность это этапа и последствий, которые принесет его отсутствие. Среди них большое время на проверку каждого элемента (страницы), и неожиданные сюрпризы в поведении продукта, увеличение затрат на исправление программы. Принцип написания тестов достаточно прост – «желтый цвет», «красный цвет», «зеленый цвет», рефакторинг. Где желтый цвет – это не созданный тест (pending), красный цвет – не прошедший тест, а зеленый – системе работает как надо.

Для каждого вида программирования, существует множество типов тестирования. Но есть и общие моменты, присутствующие везде. Так как основной род моей работы является создание web приложений под ROR, поговорим про особенности тестирования данных приложений.

Много слов сказано о том, как правильно писать юнит-тесты, и вообще о пользе TDD. Потом ещё и какое-то BDD замаячило на горизонте. Приходится разбираться, что из них лучше и между ними какая разница. Может, это и есть причина, почему большинство разработчиков решили не заморачиваться и до сих пор не используют ни того, ни другого?

Коротко: BDD — это дальнейшее развитие идей TDD, стало быть, его и надо использовать. А разницу между TDD и BDD я попробую объяснить на простом примере.

Рассмотрим 3 ревизии одного юнит-теста, который я нашёл в одном реальном проекте.

Попытка номер №1

Первая версия этого юнит-теста была такой: