Работает ли дизайн по контракту для вас?

Ответ 1

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

// @returns null iff x = 0
public foo(int x) {
  ...
}

и превращает их в сгенерированные модульные тесты, например:

public test_foo_returns_null_iff_x_equals_0() {
  assertNull foo(0);
}

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

Ответ 2

Вы действительно можете оценить дизайн по контракту, когда у вас есть интерфейс между приложениями, которые должны разговаривать друг с другом.

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

С контрактом вина виновата.

Удовлетворил ли вызывающий объект предварительные условия? Если не клиентская команда должна ее исправить.

Учитывая действительный запрос, удовлетворил ли получатель условий сообщения? Если нет, то команда сервера должна исправить это.

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

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

Ответ 3

Фрэнк Крюгер пишет:

Gaius: исключение Null Pointer автоматически генерируется автоматически во время выполнения, нет никакой пользы для тестирования этого материала в прологе функции.

У меня есть два ответа на этот вопрос:

• Нуль был просто примером. Для квадрата (x) я хотел бы проверить, что квадратный корень результата (приблизительно) - значение параметра. Для сеттеров я бы хотел проверить, что значение действительно изменилось. Для атомных операций я хотел бы проверить, что все операции с компонентами преуспели или все провалились (на самом деле один тест на успех и n тестов на отказ). Для методов factory в слабо типизированных языках я хочу проверить, возвращается ли правильный тип объекта. У этого списка нет конца. В принципе, все, что можно протестировать в одной строке кода, является очень хорошим кандидатом для кодового контракта в прологе комментария.

• Я не согласен, что вы не должны проверять вещи, потому что они генерируют исключения во время выполнения. Во всяком случае, вы должны проверить, что может генерировать исключения во время выполнения. Мне нравятся исключения во время выполнения, потому что они делают систему fail fast, что помогает отлаживать. Но null в этом примере было значением результата для некоторого возможного ввода. Там будет аргумент, чтобы не возвращать null, но если вы собираетесь, вы должны его протестировать.

Ответ 4

Абсолютно глупо не разрабатывать контракты, когда делаете что-либо в сфере SOA, и всегда полезно, если вы работаете над какой-либо модульной работой, где позже могут быть заменены биты и детали, особенно если какой-либо черный boxen.

Ответ 5

Если вы посмотрите на STL, boost, MFC, ATL и многие проекты с открытым исходным кодом, вы увидите, что существует так много утверждений ASSERTION, что делает проект более безопасным.

Дизайн-By-контракта! Это действительно работает в реальном продукте.

Ответ 6

Вместо более выразительных типов систем я бы абсолютно использовал дизайн по контракту по военным проектам.

Для слабо типизированных языков или языков с динамической областью (PHP, JavaScript) функциональные контракты также очень удобны.

Для всего остального я отбросил бы его в сторону, полагаясь на бета-тестеры и модульные тесты.

Gaius: Исключение нулевого указателя автоматически генерируется автоматически во время выполнения, нет никакой пользы для тестирования этого материала в прологе функции. Если вас больше интересует документация, я бы использовал аннотации, которые можно использовать со статическими анализаторами и т.п. (Чтобы убедиться, что код не нарушает ваши аннотации, например).

Более прочная система типов в сочетании с Design by Contract, по-видимому, является способом выхода. Посмотрите SpeС# для примера:

Язык программирования SpeС#. SpeС# является расширением объектно-ориентированного язык С#. Он расширяет тип системы для включения непустых типов и проверенные исключения. Это обеспечивает метод контрактов в форме пред- и постусловия, а также объект инварианты.

Ответ 7

Оба модульных тестирования и дизайн по контракту являются ценными подходами к тестированию в моем опыте.

Я попытался использовать Design by Contract в системе автоматического тестирования системы, и мой опыт в том, что это дает гибкость и возможности, которые нелегко получить путем модульного тестирования. Например, возможно выполнить более длинную последовательность и проверить, что время реакции ограничено каждый раз, когда действие выполняется.

Глядя на презентации в InfoQ, кажется, что дизайн по контракту является ценным дополнением к традиционным модульным тестам на этапе интеграции компонентов. Например, возможно сначала создать интерфейс mock, а затем использовать компонент after- или когда выпущена новая версия компонента.

Я не нашел инструментарий, охватывающий все мои требования к дизайну для проектирования с помощью тестирования на контракт на платформе .Net/Microsoft.

Ответ 8

Я фактически не использую Design by Contract, ежедневно. Однако я знаю, что он включен в D язык как часть языка.

Ответ 9

Да, это так! Фактически несколько лет назад я разработал небольшую основу для проверки аргументов. Я занимался SOA-проектом, в котором была реализована вся система проверки и проверки. Но для увеличения времени отклика (в случаях, когда ввод был недействительным и чтобы уменьшить нагрузку на эти серверные системы), мы начали проверять входные параметры предоставляемых услуг. Не только для Not Null, но и для шаблонов String. Или значения изнутри множеств. А также случаи, когда параметры имели зависимости между ними.

Теперь я понимаю, что мы реализовали в то время небольшой дизайн по контрактной структуре:)

Вот ссылка для тех, кто заинтересован в малой основе Java Argument Validation. Это реализовано как простое решение Java.

Ответ 10

Я нахожу, что это говорит о том, что язык программирования Go не имеет конструкций, которые делают дизайн по контракту возможным. panic/defer/recover не совсем то, что, поскольку отсрочка и восстановление логики позволяют игнорировать панику, IOW игнорировать нарушенный контракт. То, что нужно, по крайней мере, - это некоторая форма неустранимой паники, которая действительно утверждается. Или, в лучшем случае, прямая языковая поддержка дизайна по контрактным конструкциям (pre и post-conditions, реализация и инварианты классов). Но, учитывая сильную ориентацию языковых пуристов у руля корабля Go, я немного изменяю это.

Можно реализовать поведение assert-like, проверяя специальную ошибку assert в последней функции отсрочки в функции panicking и вызывая runtime.Breakpoint() для сброса стека во время восстановления. Чтобы быть утвердительным, это поведение должно быть условным. Конечно, этот подход распадается, когда новая функция отсрочки добавляется после утверждения. Что произойдет в большом проекте точно в неподходящее время, что приведет к пропущенным ошибкам.

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