Блочное тестирование PHPUnit

Привет, форумчане! Вчера в книге "Профессиональное программирование на PHP" Джорджа Шлосснейгла прочитал про блочное тестирование в PHP при помощи PHPUnit. Сражен наповал. По-моему очень-очено полезная вещь сильно недооценивается. Самое первое впечатление: есть, наконец, способ раз и навсегда забетонировать интерфейсы классов.Только теперь насчет вот этого "изменение в реализации одного класса не влияет на все систему" можно быть спокойным. Еще по-моему мвц-шники и тут оказались в шоколаде, потому что я пока с трудом представляю, как можно протестировать смешанные с интерфейсом модели.

Кто что думает про PHPUnut? Интересно, есть ли у кого наработки, как это можно приспособить к тестированию сложных вьюшек и контролеров?

Кто еще не знаком с PHPUnit, но хотел бы познакомиться, возьмите книгу отсюда http://uploadbox.com/files/pWctY5eRLZ (дежавю) Книжечка устаревшая, подозреваю, что и по PHPUnit тоже, но как вводная лекция в технологии ничего.

 

почему надо писать сначала? можно с начала, а можно по-моему на уже готовые модели натянуть тесты. Результат тот же самый.

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

 

В принципе, я и до сегодняшнего дня писал такие тесты, только не знал, что это называется умным словом "Модульное тестирование". У меня есть специальный скрипт poligon.php. Когда пишу какой- то класс, в этом скрипте как бы тестирую его и при помощи echo или watch проверяю, чтобы правильно работал. Потом, если надо, пишу для него вьюшку и в poligon.php проверяю, чтобы она правильно отображала мой класс. Меняю параметры модели и опять смотрю, как рисует ее вьюшка. Потом так же с контролером. Если через день начинаю делать новый класс, опять открываю poligon.php, стираю все что там осталось от прошлого тестирования и делаю тоже самое для нового класса. Причем неоднократно возникала мысль как то сохранить предыдущий код, потому что если рефакторинг, то приходится набирать его для той же модели второй раз. То есть я всю жизнь реально писал эти тэсты, потому что в этом реально есть необходимость.

А PHPUnit- это даже не какая- то новая технология. Это как я начал теперь понимать, просто объектно-ориентированная обвертка над тем, что мы и так всегда делаем. Просто библиотечка классов. Я даже удивляюсь, почему мне никогда в голову не приходило написать для этих целей что- то такое самому. Реально сэкономил бы кучу времени.

 

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

 

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

Можно ешё рисовать вьюшку в буфер, а потом проверять ее на валидность по HTML и CSS. Если валидна- прошла тест, если нет- не прошла. И отображать только невалидные. Вот это вообще вариант для вьюшек, по-моему. Но чтобы его сделать нужен нехилый класс- валидатор HTML/ есть такие на примете?

А вот как протестить пользовательский ввод? Для этого до сих пор приходится заходить на нужные страницы, выполнять все доступрые действия по очереди. Это долго и нудно. Иногда меняешь код в одном контролере, а от него пронаследовано еще пять. Проверять пять страниц- это уже совсем не айс. Надо придумать, как бы автоматизиравать этот процесс в PHPUnit/ Есть какие- нибудь идеи?

 

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

Да и вообще юнит- тест- это просто код, объектная обертка вокруг обычного теста, который все и так делают. А TDD- это методология разработки ПО. Как это может быть одним и тем же? Я пока собираюсь пробовать просто юнит- тесты, а потом посмотрим, может и к TDD приду.

 

ОРМ тоже кстати тестить просто. написал самый немыслемый код, который только может прийти в голову и в конце один раз сравнить с тем, что должно получиться. А транзакцию не комитить. Так что если даже там во время теста обнаружится ошибка- база не пострадает.

 

так и не услышал, почему PHPUnit- это обязательо с нуля? Что мешает накинуть по одному TestCase-у на каждую готовую модель? таким нехитрым способом тестами покроется весь проект. Есть способ проверять вьюшки и в перспективе контролеры.

спасибо посмотрю как будет время. а ссылочки нет? И что ты сам думаешь по поводу всего этого?

 

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

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

а техзадание по вашему помогает в работе?

 

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