Тест - Код - Рефакторинг - Тест

# TDD

В течение своего времени как разработчик программного обеспечения я работал в контекстах, в которых используется разработка через тестирование (TDD). Одно дело - получать от этого удовольствие (я наслаждался этим), другое - получать позитивный стимул к участию в процессе, повышающем качество и ремонтопригодность вашей работы.

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

Красный-зеленый-рефакторинг

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

Отчасти ценность процесса TDD заключается в том, что спецификация кода должна быть известна до начала работы над этим кодом.

После того, как тест написан, вводится цикл создания кода, готового к производству, который следует потоку процесса, показанному на следующей диаграмме:

Обратите внимание, что процесс TDD не мешает вам проводить рефакторинг кода и максимизировать эффективность кода, который будет запущен в производство. Это также не препятствует обычному процессу проверки кода, даже если вы, возможно, просматриваете свой собственный код в процессе работы (с тестом хорошего качества, который дает понять, имеет ли ваш код подходящее качество).

Преимущества TDD

Требование написания тестов перед кодом означает, что спецификация для любого конкретного модуля должна быть исправлена ​​до написания кода. Таким образом, требования к программному обеспечению в целом будут подтверждаться по мере разработки программного обеспечения.

Тестирование и рефакторинг встроены в процесс, который по определению поощряет строгость при создании качественного кода.

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

Процесс TDD должен экономить время при обслуживании, поскольку дефекты должны быть легко обнаружены и обнаруживаются на ранних этапах процесса разработки (отказоустойчивый метод производства).

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

Недостатки TDD

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

Задайте себе этот вопрос:

Настроен ли бизнес на TDD?

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

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

Мы можем спросить себя:

Как мы можем легко реализовать TDD в немодульной кодовой базе?

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

Это подводит нас к важному моменту. Все ли в организации на борту? Есть ли разработчики, которые думают, что они пишут идеальный код (я думаю, что уже работал с этим разработчиком; их код ужасен), которые отказываются внедрять процесс TDD? Как можно привлечь сотрудников и побудить их указывать в одном и том же направлении для выполнения отличной работы?

Заключение

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

Если вы можете разработать TDD внутри организации, если у вас есть способный персонал, это кажется обычным «простым делом». Это не означает, что это подходит для каждой организации (это не так), но вы должны делать свой собственный выбор, зная свою организацию и контекст программирования.

Контактное лицо в Twitter:

Любые вопросы? Вы можете связаться со мной ЗДЕСЬ