Уже достаточно давно в свободное время штудирую курс Test Driven Laravel, посвященный, очевидно, применению методики TDD (Test-Driven Development) к разработке ПО на Ларавеле.
Курс последовательно, начиная с написания самого первого теста, демонстрирует разработку приложения по продаже билетов на концерты. Хотя я еще не изучил и половины, должен сказать, потраченных 150$ совсем не жалко (а сейчас он уже 250$, распродажи рулят). Вещает автор бодро и понятно. Все примеры и приложение в целом можно найти в закрытом репозитории на гитхабе. Причем, каждый коммит эквивалентен одному уроку, так что без труда можно повторить всю эволюцию рассматриваемого в курсе кода.
Вообще, видео-уроки я не очень-то люблю, но здесь формат совсем не раздражает (хотя текстовый вариант все равно был бы еще круче). Так что — рекомендую.
Что же касается самой методики TDD, мне кажется, у нас ей немного не повезло с локализацией названия. У нас это называется «Разработка через тестирование», то есть слово driven редуцировали до нашего «через».
А что такое вообще в данном контексте «через»? Можно прыгнуть через лужу, или можно кинуть через известно что. Эти варианты тут, видимо, не очень подходят. Можно выйти через окно, или даже войти через дверь. Это уже ближе, но все еще непонятно.
При беглом ознакомлении с таким локализованным определением, понятно одно. Сначала надо написать тест, а потом код под этот тест. Ну ок, любопытная методика. А вот есть еще одна: можно сначала написать код, а потом не писать тест. Тоже прикольно, а главное — гораздо быстрее.
Между тем, оригинальное слово driven в названии явно обозначает подконтрольность одного явления другому. То есть, в данном случае — что ход разработки полностью подконтролен тестам, тесты ведут разработку, направляют её, что из переводной версии не очевидно.
И пока не попробуешь что-нибудь сделать «через тесты» сам, не очень-то ясно, что в самой методике главное отнюдь не наличие тестов на весь код в финале. Это лишь сопутствующая плюшка, хотя конечно тоже важная. Главное заключается как раз в слове driven. В том, что написанный тобой же тест при каждом запуске говорит тебе:
- Ты хотел по этому урлу увидеть данные, а урла такого чо-то нету. Может, добавишь?
- Вижу урл, только почему-то данных не вижу. Надо что-нибудь вывести.
- Урл пытается вывести объекты, но не знает, где их взять. Давай табличку в БД создадим?
И так далее. То есть суть в том, что если грамотно (в форме теста) описать желаемый результат, то не нужно даже особо думать, что еще ты забыл сделать и почему не работает. Лог очередного запуска теста сам тебе расскажет — чего не хватает. На мой взгляд, если эту суть осознать, методика предстает совсем в другом свете, нежели «давайте потратим в два раза больше времени, чтобы у нас был вагон тестов на каждый чих».
Как-то так.
