Даже если так говорят другие

Узнав о разработке через тестирование (TDD) и попробовав ее самостоятельно, я думаю, что моя разработка улучшилась.

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

Предположения

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

1. Создайте ритм, чтобы сосредоточиться на текущей задаче, которую необходимо решить

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

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

Решение с TDD

В TDD сказано писать тесты, но перед этим сначала грубо занесите спецификации в to-do list. После этого начинается знакомый Красный/Зеленый/Рефакторинг.

Это решает две проблемы выше:

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

Разбивайте его до тех пор, пока не станет легче писать тестовые случаи. Простой.

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

Что мы должны исправить на каждом этапе Red/Green/Refactoring, если мы застряли? Чисто.

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

2. Вы можете спокойно это исправить

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

Решение с TDD

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

3. Проблемы с дизайном можно заметить на ранней стадии, что сокращает количество переделок

Часть, с которой у меня сейчас больше всего проблем, — это детализация кода.

Как должна быть разделена обработка? Где я должен написать сплит-обработку? Такая концепция в настоящее время изучается в прогрессивной системе.

Самое сложное в проблемах дизайна то, что даже если у вас есть проблемы с дизайном, их трудно заметить, пока вы пишете только производственный код.

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

Решение с TDD

TDD усложняет написание тестов, особенно если нужно что-то исправить в дизайне. Это послужит индикатором для пересмотра дизайна.

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

4. Вы можете двигаться вперед, регулируя шаг

Одно из критических замечаний TDD заключается в том, что вам не нужно писать тесты с такой тонкой детализацией. Я не видел сцены конкретно, но критика может быть в точку. Даже если вы не опытный программист, иногда вы думаете: «Мне не нужно писать тест для этого ToDo».

Решение с TDD

В TDD есть термин «регулировка шага». TDD рекомендует писать тесты с небольшими задачами, но это не обязательно. Простой ответ: «пишите тесты, пока тревога не превратится в скуку». Это своего рода обратная связь. Так что вы должны найти ответ сами.

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

5. Его можно применить на практике относительно быстро (по сравнению с другими методами разработки) и сразу же начать действовать

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

Решение с TDD

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

Наконец

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

Дополнительные материалы на PlainEnglish.io.

Подпишитесь на нашу бесплатную еженедельную рассылку новостей. Подпишитесь на нас в Twitter, LinkedIn, YouTube и Discord .