Разработка через тестироваие для PHP программистов. Теория.

Сегодня я хочу поделиться подходом, который сделал работу над сложными PHP проектами проще, который дал мне больше свободы в написании моих программ, который спасает мои нервные клетки и делает жизнь веселее. Этот подход называется TDD, а говоря простым языком — разработка через тестирование. Об этом сказано немало, много копий было сломано в спорах, но тем не менее в среде php-разработчиков это до сих пор не стало частью процесса разработки. Я думаю основной причиной этого является специфика веб-приложений, ориентированных на интерфейсы, итеративная разработка по сценарию «пишу-смотрю-пишу-смотрю». Отдельная история это то что львиная доля разработчиков это «вебмастера», зачастую знающие о программировании «PHP за 24 часа», либо студенты с опытом написания лабораторных работ на С (эта категория настолько сурова, что даже книг не читает, именно им мы обязаны тысячам изобретенных велосипедов). С другой стороны, подкупаемые простотой написания приложений для веб и огромным спросом на них в PHP, в разработку подтянулись разработчики с опытом в Java, С, Delphi начав продвигать TDD (там юнит-тесты стали давно неотъемлемой практикой разработки). Так в чем же дело? Почему преимущества написания тестов на код не очевидны на столько, что бы все разработчики начали использовать их? Думаю всё дело в опыте. Именно с опытом приходит понимание преимуществ, которые дают ОПП, паттерны, а вместе с этим и использование TDD. Действительно, традиционный винегрет из HTML и PHP с трудом поддается тестированию и, как правило, попытки привести в порядок такой код выглядит больше не как рефакторинг, а как переписывание.

Мой путь к тестам лежал в первую очередь через осознание того что мой код хрупок. Это не так просто, как может показаться на первый взгляд, — дело в том что в программистах очень живуч миф о «совершенности» их кода. Действительно, каждый раз когда в коде находится баг, программист в первую очередь думает о том где ошибся тестировщик, а уж потом, ищет проблему в программе. Если же в вас живет скептик, критикующий производимый вами код, у вас появляется сильное желание «успокоить его», подписав логгирование, обработчики ошибок и постоянно тестируя всё что пишите. В какой-то момент, когда бизнес начинает требовать от вас радикального поворота в логике вашего приложения, и вы понимаете что для поддержания целостности приложения и уверенности в том что оно всё еще работает «как надо», вам нужно проделать такой же объём работы, который вы уже проделали, и вы понимаете — будь у вас под рукой что-то типа тестов, это спасло бы ваши выходные. То есть понимание необходимости в модульных тестах приходит именно через сложности в разработке больших и сложных приложений. Я не напрасно написал «больших и сложных», — именно так. Для простых это может показаться лишним, так как если у вас нет большого опыта работы с тестами, вы будите писать медленнее, но если опыт есть, то и для небольших проектов модульные тесты это хорошая практика, так как «большие и сложные» проекты часто вырастают из небольших, и поэтому если ваш небольшой проект спроектирован должным образом и покрыт тестами это будет отличной площадкой для развития проекта и наращивания функциональности. Если же проект большой и несложный, для веб-приложений, это как правило, большое количество пользовательских форм, простая логика сохранения и отображения информации модульное тестирование также не будет «спасательным кругом», безусловно, тесты на основные классы должны быть написаны, но главной составляющей качества вашего продукта будет скорее всего функциональное тестирование интерфейсов. А вот в случае «больших и сложных» проектов тесты, неотъемлемая составляющая проекта. В противном случае «вертолет» может «не взлететь».

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

Site Footer

Sliding Sidebar

About Me

About Me

For whom this blog for?

For those who are interested in modern Internet technologies, IT business, startups, management, quality control, personal effectiveness, motivation. Here I write about what is interesting, about problems I faced and solutions I found. I hope it will be interesting to you either.

What motivates me to write?

The desire to improve, to study deeper topics that interest me. Find people with similar problems and tasks, together look for ways out and solutions.

Feel free to contact if you have anything to say to me

Old Flash site with my artistic works and misuc.