Перевод статьи «4 Reasons You Should Write Tests First».
Люди по-разному относятся к тестам. Кто-то ненавидит их писать, а кто-то не имеет ничего против. В этой статье я расскажу о нескольких ключевых преимуществах, получаемых вами, когда вы пишете модульные или любые другие тесты. Эти преимущества незаметно, но в геометрической прогрессии улучшают ваш цикл разработки. Итак, вот четыре причины, по которым стоит подумать о написании тестов до написания кода.
Это заставляет и разработчика, и бизнес четко определять задачи
Постоянно растущие проекты с плохо прописанными user stories это, к сожалению, не такое уж редкое явление. Рано или поздно вам придется остановиться и задать ряд вопросов о том, как бизнес хочет действовать при определенном сценарии. И тут вам могут сказать сделать нечто, не имеющее ничего общего с первоначальной задачей.
А когда вы сначала пишете тесты, вы получаете ответы на все эти вопросы до того, как углубитесь в код. Также при таком подходе вы получаете некоторый контроль над масштабом каждой задачи. Чтобы написать тест для какой-то фичи, вам нужно точно знать, что она должна делать. Таким образом вы получаете шанс заранее узнать ответы на все вопросы, касающиеся бизнеса, чтобы, когда приступите к написанию кода, точно знать, что именно вы пишете и почему.
Вы удивитесь, какого прогресса вам удастся достичь, если вы будете просить представителей бизнеса озвучивать задачи, которые им нужно решить, а не пытаться изложить вам их решение. Написание тестов до написания кода гарантирует, что вы обсудили все нужные моменты, потому что без этого вы просто не сможете ничего сделать.
Это позволяет вам писать меньше кода
Вам нужно написать ровно столько кода, чтобы он прошел тест. Если тест пройден, вы покончили с этой частью работы. Когда вы занимаетесь реализацией крупной фичи, легко потеряться в коде. Тестирование помогает не сбиваться с пути и сохранять концентрацию при написании кода для этой фичи.
Прежде чем перейти к работе над следующей частью функционала, вам прежде придется закончить ту, над которой вы уже начали работать. Здесь не может быть никаких «вернусь к этому позже», потому что вы не сможете продолжить писать код, пока не пройдете первый тест. Этот подход будто немного притормаживает ваше движение, чтобы вы могли действительно хорошо обдумать, что вы собираетесь писать, прежде чем начнете собственно писать. А когда у вас будет хорошо составленный тест, вам будет несложно написать реализацию своего решения.
Это сэкономит вам целые часы, которые вы потратили бы на отладку / поддержку / регрессионное тестирование
Один из самых серьезных доводов против тестирования состоит в том, что на него уходит слишком много времени. Никто не вспоминает о случаях, когда целые дни уходят на поиск неверной логики, зато лишние несколько часов на тесты это слишком большие потери времени. А между тем, при таком подходе отладка существенно облегчается, ведь вы работаете над отдельным куском кода, не зависящим от всего остального.
Копаясь в своем коде в попытках припомнить, что должна делать каждая его часть, вы теряете гораздо больше времени. А когда вы сразу определяете тесты и пишете ровно столько кода, сколько нужно для их прохождения, все возможные проблемы видны вам сразу.
Вы можете деплоить ваш код в пятницу вечером и не бояться, что что-то сломается. Когда вам нужно обновить функционал или вы обнаружили баг, вы можете просто проверить, где провалены тесты. Плюс, при больших обновлениях или внесении изменений во многие файлы вам можно не беспокоиться о регрессионном тестировании. Несколько часов, потраченные на написание тестов, могут избавить вас от ужасных проблем.
Это ваша страховка
Иногда между миром бизнеса и миром разработки появляются расхождения. Скажем, пользователи не всегда абсолютно честны насчет того, что они делали, когда что-то сломалось. Когда у вас есть тесты, вы можете ясно показать, что это произошло не из-за вашего кода.
Даже если кто-то сделает деплоймент изменений без вашего ведома, тесты вас спасут. Вы сможете показать людям, что у вас есть эти заранее написанные тесты, и неправильный код просто не прошел бы их, разве что кто-то сделал что-то, чего не должен был делать. Тесты это ваша страховочная сеть, потому что они защищают вас от многих проблем, служа доказательством вашей невиновности.
Способы, которыми пользователи или QA-тестировщики могут что-то сломать, поистине впечатляют. Написав заранее тесты и запуская их каждый раз, когда добавляете новый код, вы обеспечиваете себе четкое подтверждение того, что все работает, как надо. Ничто другое не даст вам подобных доказательств вашей правоты.
А как вы относитесь к написанию тестов до написания кода? Я начала так делать в своих личных проектах около года назад и это изменило мой подход к программированию. Но я постоянно слышу от многих разработчиков, что написание тестов их раздражает или что им это сложно. Так что мне интересно узнать ваше мнение на этот счет. Что касается представителей бизнеса – тут все ясно, они не очень-то хотят, чтобы вы тратили время на написание тестов.
[customscript]techrocks_custom_after_post_html[/customscript]
[customscript]techrocks_custom_script[/customscript]
