Почему разработка по контракту не так популярна по сравнению с разработкой через тестирование?

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

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

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

TDD и DbC - две разные стратегии. DbC допускает отказоустойчивость во время выполнения, в то время как TDD действует «во время компиляции» (точнее, он добавляет новый шаг сразу после компиляции для запуска модульных тестов).

Это большое преимущество TDD перед DbC: он позволяет получать обратную связь раньше. Когда вы пишете код методом TDD, вы получаете код и его модульные тесты одновременно, вы можете проверить, что он «работает» в соответствии с тем, что вы считали нужным, что вы закодировали в тесте. С DbC вы получаете код со встроенными тестами, но вам все равно придется его тестировать. ИМО, это, безусловно, одна из причин того, что Dbc не так популярен.

Другие преимущества: TDD создает набор автоматических тестов, которые позволяют обнаруживать (предотвращать чтение) регрессии и выполнять рефакторинг safe, чтобы вы могли постепенно расширять свой дизайн. DbC не предлагает такой возможности.

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

Прежде всего, я инженер-программист Eiffel, поэтому могу рассказать об этом на собственном опыте.

Предпосылка TDD vs DbC неверна

Эти две технологии не противоречат друг другу, а дополняют друг друга. Дополнение связано с размещением утверждений и целью.

Цель TDD включает как компоненты, так и область применения. Основными компонентами TDD являются логические утверждения и выполнение функции объекта (например, метода). Шаги просты:

1. Создайте объект.
2. Выполните некоторый код в функции.
3. Сделайте утверждения о состоянии данных на объекте.

Утверждения, которые терпят неудачу, не проходят проверку. Цель - пройти все утверждения.

Как и TDD, контракты на разработку по контракту имеют цель, объем и компоненты. Хотя TDD ограничен временем модульного тестирования, контракты могут действовать в течение всего SDLC (жизненного цикла разработки программного обеспечения)! В рамках TDD выполнение методов (функций) объекта будет выполнять контракты. В настройке Eiffel Studio Auto-test (TDD) создается объект, выполняется вызов (точно так же, как TDD в других языках), но на этом сходство заканчивается.

В Eiffel Studio с автотестом и в коде Eiffel с контрактами цель несколько меняется. Мы хотим проверить отношения между клиентом и поставщиком. Наш код TDD притворяется клиентом нашего метода поставщика для своего объекта. Мы создаем наши объекты и вызываем методы, основанные на этой цели, а не просто на упрощенном «тестировании методов в стиле TDD». Поскольку вызовы наших методов (функций) имеют контракты, эти контракты будут выполняться как часть нашего TDD-кода в автоматическом тестировании. Поскольку это правда, утверждения (тесты) контракта, которые мы помещаем в наш код, НЕ должны появляться в нашем тестовом коде TDD. Наша задача (как программиста) просто обеспечить: A) код + контракты выполняются по всем N-путям, и B) код + контракты выполняются с использованием всех разумных типов данных и диапазонов.

Возможно, есть еще что написать об отношениях дополнения TDD-DbC, но я не буду с вами хамить по этому поводу. Достаточно сказать, что TDD и DbC НЕ расходятся с другими - далеко не во всех отношениях!

Сила контрактов DbC за пределами возможностей TDD

Теперь мы можем обратить наше внимание на силу контрактов Design-by-Contract за пределами возможностей TDD!

Контракты живут в коде. Они не внешние по отношению к нему, а внутренние. Самый важный момент (помимо договорных отношений между клиентом и поставщиком) в контрактах - это то, что компилятор спроектирован так, чтобы знать о них! Они НЕ являются неотъемлемым дополнением к Эйфелевой башне! Таким образом, они участвуют во всех аспектах наследования (как в традиционном вертикальном наследовании, так и в боковых или горизонтальных дженериках). Более того, они достигают места, недоступного для TDD - внутри метода (функции).

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

Более того, TDD не может создавать инварианты классов, кроме самых слабых способов. Я изо всех сил старался получить свой код автотеста (который на самом деле является просто версией прикладного TDD от Eiffel Studios) для имитации инвариантного класса. Это невозможно. Чтобы понять, почему вам нужно знать все детали того, как работают инварианты классов Эйфеля. Итак, на данный момент вам просто придется либо поверить мне на слово (или нет), что TDD неспособен к этой задаче, с которой DbC справляется так легко, хорошо и элегантно!

Возможности DbC не ограничиваются приведенными выше понятиями.

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

1. Workbench: вы, как программист, используете код, чтобы увидеть, как он работает (например, до TDD-времени или в сочетании с TDD-временем).

2. Модульное тестирование: ваше непрерывное интеграционное тестирование, модульное тестирование, TDD и т. Д.

3. Альфа-тест: ваши первые тестовые пользователи будут спотыкаться о контрактах при запуске исполняемого файла.

4. Бета-тест: более широкая аудитория пользователей также споткнется о контрактах.

5. Производство: окончательный исполняемый файл (или производственная система) может подвергаться непрерывному тестированию посредством контрактов (TDD не может).

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

И если всего этого было недостаточно, контракты (по замыслу) могут делать то, что не может сделать ни одно утверждение TDD: сообщает вам, где в стеке вызовов и какие отношения клиент-поставщик разорваны и почему (что тоже сразу подсказывает, как это исправить). Почему это правда?