Если вы PHP-разработчик, и по разным обстоятельствам тесты для своих приложений не пишете, то эта статья для вас. В ней я постараюсь вкратце показать с чего начать и что делать, чтобы написание тестов приносило вам радость, а вашему приложению стабильность.
Итак, первый совет. Забудьте всё что вы знаете о юнит-тестах. Швырните табуреткой в человека, который сказал вам, что без них не обойтись. Попробуем разобраться, в каких случаях нужно их использовать, а в каких — нецелесообразно.
Я абсолютно уверен, что PHP-программисты редко пишут тесты, потому что начинают не с того конца. Все знают, что тесты это хорошо и клево. Но открыв сайт того же PHPUnit, и прочитав красочный пример о тестировании калькулятора умеющего выполнять операцию a + b, они спрашивают себя: какое отношение этот калькулятор имеет к моему приложению? Ответ: никакого. Ровно как все похожие примеры, на сайтах других фреймворков тестирования. Будто бы все забыли, что PHP прежде всего для веба. Будто бы все пишут калькуляторы, а не сайты на основе MVC-парадигмы.
Положим, вы создаете сайт или разрабатываете веб-приложение. На нем уже есть некоторые страницы, формы, возможно даже интерактивные элементы. Как вы (или, допустим, ваш заказчик) проверяете что сайт работает? Наверняка вы заходите на сайт, кликаете по ссылкам, заполняете формы, смотрите на результат. И по-хорошему, все эти рутинные процессы кликанья и заполнения форм, стоит автоматизировать в первую очередь.
И потому мы поговорим о функциональных тестах (или приемочных).
Функциональное тестирование — это тестирование ПО в целях проверки реализуемости функциональных требований, то есть способности ПО в определённых условиях решать задачи, нужные пользователям. Функциональные требования определяют, что именно делает ПО, какие задачи оно решает.Википедия
Почему написание тестов стоит начать именно с них? Да просто, чтобы быть уверенным, что ваш сайт функционирует, и всё там работает. Приемочные тесты одинаково хорошо подойдут как для солидного веб-приложения, так и простенького сайта, склепанного за ночь на коленке. А потому начать стоит с них.
Что у нас есть для функционального тестирования? Из всего известного мне, это Codeception и, например, PHPUnit + Mink или прямое использование Selenium. Я хотел включить в этот печерень и Behat, но его автор попросил не использовать Behat для функционального тестирования.
Если бы тестировать с Selenium или PHPUnit + Mink было просто, вы бы уже наверняка их использовали. Потому остановимся на Codeception.
Тест в нем описывается так:
wantTo('see my site is working');
$I->amOnPage('/');
$I->see('Welcome, on my site!');
?>
Всего в несколько строчек вы проверяете, что как минимум, главная страница вашего сайта открывается. За длительной работой, сломать её, не так и сложно.
Точно так же, вы можете описывать дальнейшие действия:
click('Feedback');
$I->see('Submit your feedback');
$I->fillField('Body','Your site is great!');
$I->click('Submit');
$I->see('Thanks for your feedback!');
?>
Вот тут мы уже проверяем, что форма отзывов на вашем сайте работает. По крайней мере, пользователю, показывается, что его мнение было учтено.
Впрочем, на Хабре про Codeception я уже писал.
А теперь попробуем определиться, с unit-тестами.
Модульное тестирование, или юнит-тестирование (англ. unit testing) — процесс в программировании, позволяющий проверить на корректность отдельные модули исходного кода программы.
Идея состоит в том, чтобы писать тесты для каждой нетривиальной функции или метода. Это позволяет достаточно быстро проверить, не привело ли очередное изменение кода к регрессии, то есть к появлению ошибок в уже оттестированных местах программы, а также облегчает обнаружение и устранение таких ошибок.Википедия.
Беда их использования в том, что обычно веб-приложения основываются на CMS или фреймворках. И порой не всегда получается выделить конкретные модули для тестирования. Особенно неудобно получается, когда логика приложения раскидана по различным классам, а каждый конкретный юнит по сути не делает ничего. Процесс тестирования ещё будет усложнен тем, что все модули как-то взаимосвязаны, имеют много унаследованых методов, конфигураций, и выделить где код ваш, а где код библиотеки порой очень трудно.
Но если в рамках функциональных тестов вы проверили всё, что пользователь может сделать, то в юнит-тестах постарайтесь учесть, что он не должен сделать.
Например, проверьте, не позволяет ли ваш код создавать двух пользователей с одинаковыми именами. Проверьте, что при попытке создать дубликат приложение не упадет, и не покажет белый экран смерти, а перехватит ошибку и покажет её текст пользователю. Согласитесь, пользователь, может натворить, гораздо больше, чем вы того хотите. А потому предусмотреть все возможные сценарии и покрыти их функциональными тестами порой невозможно.
Или ещё один пример: у вас на сайте акция — каждый 100ый зарегистрированый пользователь получает подарок. Как бы так проверить, что подарки выдаются, и не создавать при этом 100 лишних пользователей? Вот тут уже пишите юнит-тесты. Без них, скорее всего, никак.
Если в вашем приложении четко выражена бизнес-логика, например: «этот метод создает пользователя, а этот метод позволяет менять статус группы», то вполне резонно покрыть и такие методы юнит-тестами.
Для юнит-тестирования фреймворков много:
PHPUnit
Atoum
EnhancePHP
SimpleTest
Testify
Как альтернатива традиционным юнит-тестам:
PHPSpec
Spectrum (c отличной документацией на русском).
тот же Codeception. Как ни странно, о нем я тоже писал.
Опять таки, выбирайте сами. PHPUnit, это конечно стандарт, но более современные фреймворки могут быть проще и эффективнее.
Резюмируя, я бы сказал так: тесты действительно нужны и они не так страшны, как вам могут представляться. Начните написание тестов с приемочных, продолжте модульными. Тестируйте то, что важно и тестируйте то, в чем не уверены.Disclaimer: прошу прощения за ряд намеренных упрощений и неточностей в статье. С моей точки зрения, они необходимы, чтобы объяснить базовые принципы автоматического тестирования PHP-приложений. Чем больше людей будут тестировать свои приложения, тем лучше станет мир. Ведь главное — начать.
