Многие программисты игнорируют важность тестирования ваших приложений, иногда тесты выполняются на локальном хосте.

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

Страх перед производственной средой

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

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

Итак, TDD — это ключ к управлению страхом во время программирования.

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

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

В статье, созданной Боби Джорджем и Лури Уильямсом с участием 6 групповых пар программистов, из которых 6 пар TDD и 6 контрольных пар, всего 24 профессиональных разработчика, они считают, что

  • 87,5% — подход TDD способствует лучшему пониманию требований
  • 95,8 % — сокращение усилий по отладке
  • 50,0% — считают, что TDD сокращает время разработки кода.
  • 78,0% — Мысль, что TDD повышает общую производительность

По вопросам эффективности

  • 92,0% — считают, что TDD дает более качественный код
  • 79,0% — Считают, что TDD способствует упрощению дизайна
  • 71,0% — считают, что такой подход был заметно эффективнее
  • 80,0% — Считают, что TDD эффективен

Но принятие мышления TDD было трудным, в статье было 56% профессиональных разработчиков, для меня тоже, но мой совет:

  • Вы должны понимать продукт, с которым работаете
  • Вам необходимо понимать функциональные требования, которые вы будете реализовывать
  • Тренироваться нужно каждый день :)

Заключение

Рост компании в более быстром режиме

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

Тогда что, по вашему мнению, лучше: инвестировать в команду разработчиков, которая тратит больше времени на создание функций или исправление ошибок?

Страх перед рефакторингом

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

Рекомендации

Боби Джордж и Лори Уильямс. 2003. Первоначальное исследование разработки через тестирование в промышленности. В материалах симпозиума ACM 2003 г. по прикладным вычислениям (SAC '03). Ассоциация вычислительной техники, Нью-Йорк, штат Нью-Йорк, США, 1135–1139 гг. https://doi.org/10.1145/952532.952753