Разработка через тестирование (TDD): устранение ошибок до нулевого дня

Писать софт сложно. Хорошо разработанное программное обеспечение требует самоотверженности, вдумчивости и готовности разгрузить будущих разработчиков.

И нужны тесты. Много тестов.

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

Звучит знакомо?

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

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

Но как?

Разработчики должны перейти от менталитета производственной линии к менталитету мастера.

Искусство написания программного обеспечения основано как на творчестве, так и на аналитическом решении проблем.

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

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

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

Разработка через тестирование (TDD) — ключевой процесс в этом ремесле.

Вот мои основные причины «почему TDD» в произвольном порядке:

1. Вы все равно будете писать тесты.

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

2. Получите правильную обратную связь как можно раньше.

Когда вы пишете тест после того, как код написан, вы сосредотачиваетесь на «самопроверке», гарантируя, что код работает так, как вы сказали, — это наиболее ярко проявляется в тяжелых насмешках. Когда вы пишете тест перед кодом, вы сосредотачиваетесь на том, как API должен соответствовать бизнес-требованиям.

3. Знайте цель, прежде чем писать план.

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

4. Создавайте программное программное обеспечение, а не **аппаратное обеспечение — разница в доверии.

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

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

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

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