Разве разработка через тестирование (TDD) не вдвойне труднее? Вы все равно должны это сделать?

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

Что вы не учитываете, так это количество времени, необходимое для тестирования и отладки QA, когда функция не работает должным образом.

Тематические исследования были проведены с тремя группами разработчиков в Microsoft и одной в IBM, которая внедрила TDD. Результаты тематических исследований показали, что плотность дефектов до выпуска четырех продуктов снизилась на 40–90% по сравнению с аналогичными проектами, в которых не использовалась практика TDD.

Субъективно, после внедрения TDD время начальной разработки команд увеличилось на 15–35%. ("источник")

Снижение количества дефектов до выпуска на 40–90% означает, что группы контроля качества и клиенты не находили и не сообщали об этих проблемах. Инженеры не пытались воссоздавать ошибки и разрабатывать исправления, все из которых имели связанные с этим расходы.

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

Что такое TDD?

Разработка через тестирование - это подход к написанию программного обеспечения, при котором разработчик использует спецификации для определения способа реализации функции. Для краткости мы описываем это как «цикл рефакторинга красный-зеленый».

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

Почему вам стоит заботиться о TDD

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

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

Давайте обсудим некоторые действительно интересные преимущества TDD.

1. TDD помогает предотвратить ошибки

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

2. Самообъясняющий код (хорошо документированный)

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

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

3. Избегайте проблемы с отладчиком ошибок.

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

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

Например:

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

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

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

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

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

4. Вы можете предвидеть неприятности.

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

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

5. Экономьте деньги

Когда код сложен, сделать что-либо становится намного сложнее - одно небольшое изменение здесь может привести к большой проблеме. Следуя TDD, разработчики могут с уверенностью вносить изменения, и ваша команда QA поймает меньше регрессов. Говоря языком разработки, «сэкономленное время равно заработанным деньгам».

6. Инвестируйте сэкономленное время в инновации и исследования.

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

7. TDD помогает избежать сползания прицела

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

Расползание объема может происходить по разным причинам: плохо сформулированные задачи, неверное толкование требований проекта, отсутствие документации и т. Д. Существует множество методов, направленных на снижение сползания области видимости, и TDD - один из них.

Спасибо за прочтение! Поделитесь, если вы нашли это полезным :)