[описание особенностей SimpleTest для PHP]материал подготовил: А. В. Кириллов 29.12.2005
Технология экстремального программирования предполагает наличие определенных стартовых условий. Например, вы должны быть готовы с самого начала проектирования внедрить в ваш проект избыточный код. Причем по мере увеличения функциональности задачи этот код также должен разрастаться в объемах. Основное его назначение – проверка работоспособности ваших классов и функций, а также тестирование входных и выходных данных для приложения. В моей первой статье (“Функции тестирования в PHP-проектах”) про применение технологий ударного проектирования (или экстремального программирования, как называют его большинство разработчиков) был сделан упор на концепцию введения таких методов проектирования в уже готовый проект. В сегодняшнем материале я хотел бы сделать упор на применение готового программного обеспечения, которое создано специально для внедрения таких технологий в готовые и проектируемые системы. итак, сегодняшняя статья прольет немного света на SimpleTest.
В отличие от простейшего подхода к организации тестирования путем самостоятельного написания методов проверки классы SimpleTest позволяют кардинально расширить возможности тестируемого кода. идеологически само тестирование бета-кода происходит в обертке класса, который наследует возможности базового объекта SimpleTest. Этот базовый класс позволяет выполнять массу стандартных действий вроде проверки значения переменной на True или False и выдачи сообщений. Таким образом, если вы решились на введение профессионального подхода к решению проблемы автоматического тестирования в вашем веб-приложении, следует быть готовым к довольно частому применению объектного кода и переносу части вашей функциональности в PHP-классы. итак, с чего же начать сам процесс перевода вашей задачи на рельсы экстремального программирования? Вначале на все том же SourceForge скачиваем программные модули для тестирования. Следует отметить, что программный продукт хоть и совершенно работоспособен, но находится в стадии альфа-тестирования, что должно откладывать некий отпечаток на весь процесс вашего ознакомления с ним (например, надо быть готовым отправить отчет про найденную вами ошибку его разработчикам). Далее размещаем содержимое архива в подкаталоге simpletest вашего веб-приложения. После этого следует определиться с перечнем функций вашей задачи, которые необходимо в первоочередном порядке подвергнуть тестированию. Их можно отобрать как по критерию частоты использования, так и по другим критичным именно для вашего приложения параметрам. Например, можно отобрать для начала наиболее длительные по времени исполнения или наиболее часто корректируемые функции.
Следует заметить, что в плане удобства для самого разработчика к задаче тестирования любого веб-приложения можно применить два подхода. Можно встроить код тестирования в саму задачу и тем самым перенести часть ответственности за тестирование приложения на плечи пользователей (мало ли какая ошибка вылезет в процессе использования ваших скриптов) либо изначально разделить местоположение тестируемого кода и основного веб-приложения. В любом случае отличной идеей будет включение функциональности тестирующего кода в итоговое веб-приложение хотя бы в качестве дополнительной информационной службы для команды разработчиков. Поэтому, наверное, самым подходящим местоположением для функций SimpleTest будет одноименный подкаталог вашего веб-приложения. Разместив скрипты таким образом, вы получаете возможность проверять код, уже находящийся на стороне сервера, что достаточно удобно как в плане поддержки веб-приложения, так и в плане защищенности самого заказчика от посягательств на его безопасность.
Для демонстрации процесса попробуем вынести в обязательно тестируемые функции часть класса, предназначенного для выдачи сообщений пользователям и ведения текстового лога. Для простоты изло
