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. Таким образом, вам предлагается единый интерфейс для написания функциональных тестов практически для любого сайта.

Давно хотел поделиться с общественностью способом тестировать код, использующий функции для работы с внешней средой: с сокетами, БД, файлами и чем угодно ещё. Сегодня, увидев статью Runkit + PHPUnit = 100% покрытие тестами, решил, что сейчас самое время.
Решение с Runkit красивое, но есть одна проблема — Runkit не распространяется вместе PHP, его надо ставить отдельно. Я же хочу предложить подход, работающий в обычной поставке PHP 5.3+, при одном условии — проект должен использовать пространства имён.

Здравствуйте, уважаемые коллеги.

Одним из косвенных показателей качества кода считается code coverage — степень покрытия его тестами (как правило, имеются в виду модульные тесты). В большинстве случаев за coverage принимается соотношение количеству строк кода, в котрое попадает управление во время прогона тестов, к общему числу значимых (не являющихся комментарием, пустой строкой, или, например одной фигурной скобкой, обозначающей начало или конец блока) строк кода модуля.

Другим же условием хороших тестов является отсутствие сторонних эффектов (side effects), как например создание/удаление файлов, установка сетевых соединений, запись в порты и т.д.

Однако, когда дело касается модуля, взаимодествующего с внешним миром, эти два требования вступают в противоречие. И ладно, если речь идет о файловых операциях, когда на помощь приходит vfsStream. Но что делать, когда надо тестировать, скажем, прямую работу с сокетами или код, использующий функции curl_*?

Под катом вы найдете мое решение и, в качестве бонуса, еще одну ОПП-обертку к курлу, полностью покрытую тестами.

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

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

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

Существует цепочка в мозгу: мы напишем юнит тесты, затем эти тесты нам расскажут если мы что-то сломали, затем они нам почту будут отправлять о том, что проект поломался.
Это ничто иное, как иллюстрация непрерывной интеграции (Continious Integration) нычне крайне модного направления гибкой разработки. Единственный недостающий элемент цепочки — «КАК». Ниже коротенький рецепт, как бы отвечающий «очень просто».

Дисциплина «Метрология программного обеспечения» входит в учебный план подготовки дипломированных специалистов по направлению 654600 — «Информатика и вычислительная техника» по специальности 220400 — «Программное обеспечение вычислительной техники и автоматизированных систем». Дисциплина изучает проблемы оценки метрических характеристик качества ПО на этапах от разработки спецификаций до завершения отладки и тестирования программного продукта. В курсе рассматриваются критерии, характеристики и метрики качества ПО; особый упор делается на характеристики корректности, надежности и сложности программ. Изучаются формальные модели и методы оценки как статических, так и динамических характеристик качества ПО, позволяющие на различных стадиях разработки выявлять просчеты и дефекты программного изделия. Рассматриваются инструментальные средства поддержки и автоматизации измерения характеристик ПО.

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