Поделитесь опытом по сабжу – не могу заставить PhpUnit запускаться для контроллеров и моделей.
Поделитесь опытом по сабжу – не могу заставить PhpUnit запускаться для контроллеров и моделей.
Клуб программистов работает уже ой-ой-ой сколько, а если поточнее, то с 2007 года.
1 ноября 2009 в 1:03
Да, конечно трудности были и периодически возникают. Наиболее трудным местом стала организация тестовых файлов. Например как совместить в одном тестовом наборе приемочные тесты и тесты модели. Им нужна разная среда исполнения- одним для работы надо корректно инициализировать все приложение, другим достаточно PHPUnit и ZFв include_path и еще пары строк инициализации. Вариантов много. Распихивать их по разным папкам test c повтором в каждой структуры каталогов… можно, но как-то не хочется разделять тесты таким образом, да и хочется иметь возможность прогнасть сразу все тесты одной командой. Мой выход – в корне тест созданы 2 разных bootstrap файла, которые производят необходимую конфигурацию для обоих случаев. Следующий вопрос – что использовать phpunit.xml, выполнение тестов по каталогам или PHPUnit_Framework_TestSuite? phpunit.xml – удобно, просто, но не подходит для моего случая. Я нацелен использовать в своих разработках автоматическую сборку на базе phing, а там тесты с phpunit.xml не поддерживаются. TestSuite – тоже удобно, мне кажется даже самый мощный вариант, но это подразумевает использование методики AllTests.php, а это опять phing не очень любит. Поэтому остановился на выполнении тестов по директориям, это оказалось не менее удобно чем остальные варианты. В каждом тесте подключается необходимый bootstrap и это все что нужно для их работы как в целом так и по отдельности. Хотя тут тоже есть нюансы, на 100% пока систему не отладил.
Далее по организации загрузки тестовых данных. Использую PHPUnit_Extensions_Database_TestCase для полной очистки всех необходимых для теста таблиц и занесения в них тестовых данных (DataSet). Считаю это очень удобным, но несколько бедноватым классом. Например он требует экспорта в бд одних и тех же данных перед каждым тестовым случаем (метод getDataSet() выполняется в setUp()), но случаи как известно бывают разные. Поэтому в методе getDataSet() я загружаю только очищающий конфиг. А данные вставляю требуемые в конкретном тесткейсе. Хотя в документаци по PHPUnit функционал этого расширения описан на 50%, посмотрев в исходники убедился что возможностей больше.
1 ноября 2009 в 0:05
это-то все давно перечитано
интересует конкретный, личный опыт и реальные трудности, которые приходится решать
как, например, организация загрузки тестовых данных
1 ноября 2009 в 0:03
Ничего нового про best practices рассказать не могу, тем более про свои, поскольку все они не мои и уже изобретены до нас
. Не буду пресказывать то, что уже сказали другие, просто приведу несколько очень полезных статей с примерами. Сам разрабатываю и тестирую модели подобно описанныму в этих источниках.
1) Книга //www.survivethedeepend.com
Главы 3. The Model и 9. Implementing The Domain Model: Entries and Authors. В главе 9 на наглядном примере показана разработка модели через тестирование. Если покопаться в инете, можно найти исходники.
Отдельная глава, которую автор назвал "Unit Testing And Test Driven Design (TDD)" еще не написана, но обещал скоро дописать.
2) //weierophinney.net/matthew/archives/202-Model-...
Статья лидера ZF (Мэтью) о инфраструктуре модели приложения. Примерно к такой модели следует стремиться.
3) //www.slideshare.net/weierophinney/zend-framewo...
Скринкаст Мэтью, охватывающий "правильное" написание приложений на ZF в целом.
4) В качестве руководства по best practices TDD крайне рекомендую книгу Кента Бека – Экстремальное программирование. Разработка через тестирование (поищите на proklondike.com).
30 октября 2009 в 23:05
напишите ваши best practices по тестированию моделей, интересно
30 октября 2009 в 22:04
Приветствую. Смотрю с момента последнего поста почти год прошел.
Поделюсь своим опытом. Сразу хочу сказать, что юнит тесты, написанные с помощью Zend_Test являются по своей сути "приемочными тестами" – они показывают что в результате действий пользователя показываются корректные страницы, данные на них, правильные редиректы и тому подобное, поскольку позволяют правильно инициализировать все приложение и провести эмуляцию http запроса… то есть они более полезны для заказчика чем для разработчика. (но от этого их важность не преуменьшается). Разработчику же более полезны тесты модели приложения. Их удобнее писать используя чистый PHPUnit (без Zend_Test_PHPUnit_ControllerTestCase). Удобнее потому что модель является автономным набором классов, не зависящей от остальной части приложения и поэтому не требующей инициализации самого приложения, подгрузки контроллеров и видов.
Рассмотрим TDD модели приложения. Для любых тестов необходимо настроить среду тестирования. Общепринятым способом является использование Bootstrap.php или TestHelper.php, которые инклудятся в каждом тесте. В задачи этих файлов входит например следующее: установка пути к приложению, добавление необходимых путей в include_path, настройка автозагрузки классов. Для автозагрузки можно использовать например
spl_autoload_register(create_function('$class', "include str_replace('_', '/', \$class) . '.php';"));
Это позволит загружать классы, соответствующие соглашению Zend об именовании файлов и классов (например автоматом загрузит Class_Name(), расположенный в каталоге <include_path>/Class/Name.php).
В более сложных случаях для настройки автозагрузки лучше использовать Zend_Loader_Autoloader.
В случае приемочного тестирования с Zend_Test как правило автозагрузка уже настроена, так как используется конфигурационный файл самого приложения.
Другой вопрос – организация тестовых файлов. Об этом позже.
27 ноября 2008 в 13:04
Раскажи здесь о "граблях" в PHPUnit
26 ноября 2008 в 21:00
Да, прикрутили. И, кстати, получилось запускать PHPUnit.
26 ноября 2008 в 11:03
2Илья Болховский:
Это я знаю. Но я весь в работе и не разбирал еще Zend_Amf. Я так понимаю эта компонента предназначена для "общения" PHP с Flash. Для меня это пока не актуально
17 ноября 2008 в 21:02
Хахах, да я как-бы помощи и не ждал. Ок, напишу.
Кстати, вышел пререлиз ZF 1.7 с новой компонентой amf. На неделе будем привинчивать.
17 ноября 2008 в 12:01
Млять, времени совсем нету. Извини дружище, я пока тебе ничем не помогу
((
17 ноября 2008 в 12:01
Но если ты решиш этот вопрос – обязательно напиши здесь. ОК?
1 ноября 2008 в 0:02
Вся фишка в том, что нужно правильно настроить инклюды. А вообще Zend Studio рушит всю идею – время от запуска до выполнения одного теста занимает около полминуты, а то и больше. Это оочень долго, и никакого удовольствия от TDD не получаешь. Рельсы рулят все-равно.
31 октября 2008 в 11:05
Не работал пока с этим. А что ман. по этому поводу говорит?
Я на выходных почитаю и поэксперементирую. Выводы по сабжу напишу здесь
31 октября 2008 в 11:05
Разработка через тэстирование – хорошая вещь. Уже давно планировал освоить. Посмотрю