Разработка через тестирование: плюсы и минусы?

Разработка через тестирование Изучение

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

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

Сегодня мы рассмотрим TDD, а также преимущества и недостатки использования этого подхода.

Разработка через тестирование: обзор

TDD связан с принципами экстремального программирования, но также приобрел популярность в различных контекстах. Экстремальное программирование — это тип гибкой разработки программного обеспечения, предназначенный для улучшения качества программного обеспечения и его способности реагировать на изменяющиеся требования. Кент Бек, разработавший экстремальное программирование в конце 1990-х, говорит, что заново открыл подход «сначала тесты» из старого руководства по программированию. Позже он написал собственную книгу по TDD: Test-Driven Development: By Example.

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

Что такое единицы ? Модули — это наименьшие фрагменты кода в программе, которые повторяемы, тестируемы и функциональны.

5 шагов TDD: от модульных тестов до рефакторинга

Мы можем рассматривать TDD как итеративный цикл с пятью шагами:

  1. Разработчик пишет модульный тестдля новой функции на основе спецификаций.
  2. Разработчик запускает все существующие модульные тесты. Вновь созданный модульный тест должен завершиться ошибкой, поскольку код для его функции еще не написан. Это подтверждает, что тест был необходим.
  3. Разработчик пишет простейший код, необходимыйдля прохождения модульного теста.
  4. Разработчик реорганизует новый код, чтобы улучшить его удобочитаемость и удобство сопровождения.
  5. Разработчик повторяет процесс, в конечном итоге собирая новые тесты для каждой предполагаемой функции кода.
Читайте также:  Как создать MVP в банковском деле и финансах?

Рефакторинг и другие принципы TDD

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

Согласно TDD, рефакторинг должен продолжаться до тех пор, пока исходный код не будет соответствовать критериям простоты. Эти критерии, разработанные Беком, предназначены для определения того, является ли некоторый объем исходного кода «достаточно простым». Эти критерии также известны как правила простого дизайна и перечислены в порядке приоритета:

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

Бек — далеко не единственный человек, который вносит свой вклад в соглашения TDD. Инженер-программист Роберт С. Мартин усовершенствовал этот подход, обобщив свои идеи в трех правилах TDD :

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

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

Эти правила предназначены для обеспечения написания всего

Преимущества TDD

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

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

IBM выделяет и другие преимущества TDD:

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

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

Недостатки TDD

Подход «сначала тестирование» работает не для всех. Agile Alliance определяет некоторые распространенные ловушки.

Физические лица могут:

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

Команды могут:

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

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

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

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

Связанные подходы к разработке

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

Разработка через приемочное тестирование (ATDD)

ATDD аналогичен TDD, но с упором на процесс приемочного тестирования. Приемочные тесты — это формальные описания того, как должны вести себя готовые программные продукты. Обычно они имеют форму примеров или сценариев использования. В ATDD члены команды, участвующие в приемочном тестировании, представляют три заинтересованные стороны: заказчиков, разработчиков и тестировщиков.

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

Развитие, управляемое поведением (BDD)

BDD объединяет и совершенствует методы TDD и ATDD, уделяя особое внимание тому, чтобы продукты соответствовали бизнес-целям. Этот подход тщательно изучает предлагаемые пользовательские истории, чтобы убедиться, что цель теста четко связана с бизнес-результатами.

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

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

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

Заключение

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

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

Если вы работаете с Java и хотите улучшить свои навыки модульного тестирования, вы можете изучить JUnit.

Оцените статью
bestprogrammer.ru
Добавить комментарий