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

Дизайн контракта и разработка через тестирование не взаимоисключающие .

книга Bertrand Meyer Разработка объектно-ориентированного программного обеспечения, 2-й Выпуск не говорит, что Вы никогда не делаете ошибки. Действительно при рассмотрении главы, "Когда условия контракта нарушены", обсуждает это то, что происходит, когда функции не удается выполнить то, что говорит ее контракт.

очевидный факт, что Вы используете метод DbC, не делает Ваш код корректным. Дизайн контракта устанавливает четко определенные правила для Вашего кода и его пользователей, в форме контрактов. Это полезно, но можно всегда портить вещи так или иначе, только что Вы, вероятно, заметите ранее.

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

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

Это - большое преимущество TDD по DbC: это позволяет получать более раннюю обратную связь. При написании кода TDD путь Вы получаете код и его модульные тесты одновременно, можно проверить, что он "работает" согласно тому, что Вы думали, что он должен, который Вы закодировали в тесте. С DbC Вы получаете код со встроенными тестами, но все еще необходимо осуществить его. IMO, это, конечно - одна причина, что Dbc не так популярен.

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

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

Я думаю, лучше использовать оба метода в соединении, а не всего один или другой.

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

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

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

В моем уме TDD является более "индуктивным". Вы запускаете с примеров (тестовые сценарии), и Ваш код воплощает общее решение тех примеров.

DBC кажется более "дедуктивным" после собирающихся требований, Вы определяете поведение объекта и контракты. Вы затем кодируете определенную реализацию тех контрактов.

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

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