Плюсы и минусы разработки через тестирование

Каковы плюсы и минусы разработки через тестирование (TDD)?

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

Идея состоит в том, что сначала эти тесты не пройдут, а затем вы начнете писать достаточно кода, чтобы попытаться пройти все тесты. Пройдение всех тестов может быть мерой критериев выполнения (dev-done), а также повышает уверенность в качестве кода.

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

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

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

Теперь о плюсах и минусах TDD:



Плюсы разработки через тестирование

  • Поскольку вы пишете небольшие тесты за раз, это заставляет ваш код быть более модульным (в противном случае их было бы трудно протестировать). TDD помогает вам изучить, понять и усвоить ключевые принципы хорошего модульного дизайна.
  • TDD также требует хорошей архитектуры. Чтобы сделать ваш код модульно-тестируемым, он должен быть правильно разбит на модули. При написании тестов в первую очередь различные архитектурные проблемы, как правило, проявляются раньше.
  • Документирует ваш код лучше, чем документация (он не устаревает, так как вы используете его постоянно).
  • Облегчает обслуживание и рефакторинг кода. TDD помогает внести ясность в процесс реализации и обеспечивает страховку, когда вы хотите провести рефакторинг только что написанного кода.
  • Делает совместную работу проще и эффективнее, члены команды могут с уверенностью редактировать код друг друга, потому что тесты сообщат им, если изменения приводят к неожиданному поведению кода.
  • Поскольку TDD по сути заставляет вас писать модульные тесты перед написанием кода реализации, рефакторинг кода становится проще и быстрее. Код рефакторинга, написанный два года назад, жесткий . Если этот код подкреплен набором хороших модульных тестов, процесс станет намного проще.
  • Помогает предотвращать дефекты - ну, по крайней мере, помогает найти проблемы с дизайном или требованиями с самого начала. TDD обеспечивает раннее предупреждение о проблемах проектирования (когда их легче исправить).
  • Помогает программистам действительно понимать свой код.
  • Создает набор автоматических регрессионных тестов, в основном бесплатно. то есть вам не нужно тратить время после написания модульных тестов для тестирования кода реализации.
  • Он поощряет небольшие шаги и улучшает дизайн, потому что заставляет вас сокращать ненужные зависимости, чтобы облегчить настройку.
  • Это помогает прояснить требования, потому что вам нужно конкретно выяснить, какие входы вы должны использовать и каких результатов вы ожидаете.
  • Модульные тесты особенно ценны как подстраховка, когда код необходимо изменить, чтобы добавить новые функции или исправить существующую ошибку. Поскольку на техническое обслуживание приходится от 60 до 90% жизненного цикла программного обеспечения, трудно переоценить, как время, затраченное на создание приличного набора модульных тестов, может окупаться снова и снова на протяжении всего жизненного цикла проекта.
  • Тестирование во время написания также заставляет вас попытаться сделать ваши интерфейсы достаточно чистыми, чтобы их можно было протестировать. Иногда трудно увидеть преимущества этого, пока вы не поработаете над частью кода, где этого не было, и единственный способ потренироваться и сосредоточиться на данном фрагменте кода - запустить всю систему и установить точку останова. .
  • «Глупые» ошибки выявляются практически сразу. Это помогает разработчикам находить ошибки, которые, если бы они были обнаружены в отделе контроля качества, зря потратили бы время.

Минусы разработки через тестирование

  • Сам набор тестов необходимо поддерживать; тесты могут быть не полностью детерминированными (т.е. зависеть от внешних зависимостей).
  • Написание тестов может быть трудным, особенно. за пределами уровня модульного тестирования.
  • Изначально тормозит развитие; для быстро итеративных сред запуска код реализации может быть не готов в течение некоторого времени из-за того, что сначала нужно потратить время на написание тестов. (Но в конечном итоге это действительно ускоряет разработку)
  • Как и в любом программировании, есть большая разница между тем, чтобы делать это хорошо, и делать это хорошо. Написание хороших модульных тестов - это искусство. Этот аспект TDD часто не обсуждается, многие менеджеры склонны сосредотачиваться на таких показателях, как покрытие кода; эти показатели ничего не говорят вам о качество юнит-тестов.
  • Модульное тестирование - это то, на что должна согласиться вся команда.
  • Задача учиться. Это может быть пугающим, и поначалу никому не легко научиться этому, особенно если вы пытаетесь выучить его самостоятельно. Это требует большой самоотдачи (дисциплина, практика, настойчивость), и у вас должна быть цель, которую вы хотите постоянно улучшать.
  • Трудно применить к существующему унаследованному коду.
  • Множество заблуждений, мешающих программистам изучить его.
  • Трудно начать работать таким образом. Особенно, если вы много лет работаете другим способом.
  • Иногда приходится издеваться над множеством вещей или вещей, над которыми сложно высмеять. Это полезно в долгосрочной перспективе, но болезненно сейчас.
  • Вы должны постоянно заниматься домашним хозяйством. Поскольку резервирование все большего числа тестов делает вашу сборку все длиннее и дольше, необходимо доработать эти тесты, чтобы они выполнялись быстрее или удалили повторяющиеся тесты.
  • Как и любой хороший метод, модульное тестирование можно довести до крайности. Наибольшие преимущества дает умеренное усилие, когда тесты всегда проверяют код самым простым способом. Если вы часто занимаетесь рефакторингом тестов, скорее всего, вы тратите слишком много времени на набор тестов.
  • Можно легко отвлечься на «ерунду» или необычные функции фреймворка модульного тестирования. Мы должны помнить, что простые тесты быстрее всего создавать и легче всего управлять.
  • Хотя это абсолютно необходимо, создание тестов на сбой может быть утомительным, но в конце концов окупается.
  • Рефакторинг на ранней стадии также требует рефакторинга тестовых классов.
  • Если все в команде не будут правильно проводить свои тесты, вся система может быстро выйти из строя.