Умный поиск

Аналогии TDD: Проектирование сооружений через тестирование

Введение в разработку через тестирование

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

Традиционная схема тестирования предполагает, что программный код уже написан. Фактически, в таком случае проверяется работа существующей программы. Однако сравнительно недавно, в самом конце XX века, была предложена новая концепция, согласно которой тестирование проходит параллельно с разработкой основного кода, и даже незначительно опережает его. Таким образом, на некоторых этапах разработки программного обеспечения оказывается, что тестируемый код еще не создан! Абсурд? Не совсем. Давайте разберемся.

Такая техника получила название "Разработка через тестирование" (Test-Driven Development, TDD). Основная её идея состоит в том, что разработка программного обеспечения дробится на небольшие этапы, каждый из которых начинается с теста. Тест формирует требования, предъявляемые к основному коду, который напишется позже. Таким образом, программисту удаётся оценить эффективность кода заранее (как бы взглянуть на программу со стороны пользователя), упредить некоторые затраты времени, более основательно подготовиться к реализации. По мнению авторов, TDD как независимая методология "поощряет простой дизайн и внушает уверенность", а также реализует "инверсию ответственности", потому что между качеством тестов и качеством основного кода существует прямая зависимость.

Аналогии TDD: Проектирование сооружений через тестирование | Dystlab Library

Malas Ideas (предоставлено: Flickr)

Как применить TDD в проектировании сооружений

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

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

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

Тест как оценка риска конструкции

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

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

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

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

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

TDD в техническом образовании

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

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

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

Другие статьи по теме TDD

  1. Разработка через тестирование / Wikipedia
  2. TDD. Интересные публикации / Хабрахабр
  3. Introduction to Test Driven Development (TDD) / Agile Data


Виталий Артемов — фото профиля

Виталий Артемов

Основатель, руководитель лаборатории Dystlab. Кандидат технических наук, разработчик САПР. Ведет онлайн-курсы по расчету конструкций, динамике, спецкурс для аспирантов, руководит стажировкой по расчету ЖБК


Блог | Этот адрес электронной почты защищён от спам-ботов. У вас должен быть включен JavaScript для просмотра. | Community | FB | LinkedIn

Под статьей | Случайные статьи по инженерии