Выполнен (http://www.opennet.ru/base/dev/DesignByContract.txt.html) перевод на русский язык документации Eiffel по технологии проектирования по контракту (Design by Contract).Широко распространенным способом тестирования программных
компонент является выполнение юнит-тестов. Юнит-тесты описывают набор
шагов, которые необходимо выполнить, для получения необходимого
результата. Однако юнит-тесты трудно писать и поддерживать в актуальном
состоянии, отсутствие декларативности и интеграции в код затрудняет
понимание спецификации программного компонента, объём кода юнит-тестов,
как правило, достаточно велик. Этих недостатков лишены контракты,
которые накладывают ограничения и обязательства на компоненты класса.
Контракты являются частью документации программной системы, позволяют
легко тестировать отдельные компоненты, упрощают повторное
использование и отладку.
Проектирование по контракту изначально
поддерживается в языке Eiffel как на уровне инструментов среды
программирования EiffelStudio, так и во всех стандартных библиотеках,
поставляемых с этой средой. Систематическое применение проектирования
по контракту позволяет упростить проектирование программных систем,
сократить время выявления ошибок, повысить качество кода и надежность
разработанного ПО.URL: http://www.opennet.ru/base/dev/DesignByContract.txt.html
Новость: http://www.opennet.ru/opennews/art.shtml?num=36353
Я так понимаю, аннотация не с английского переводилась? Потому что в ней, простите, чушь написана.Контракты и юниттесты - заимно дополняющие друг друга технологии. Хотя бы потому, что контракты проверяются только на том code path, по которому пошло исполнение программы, а юниттесты позволяют прогнать (в идеале) каждый code path (и, в том числе, осбеспечить проверку контрактов при этом).
> юниттесты позволяют прогнать (в идеале) каждый code pathЮнит-тесты позволяют протестировать валидность поведения кусочков программы ("юнитов"). Протестировать все возможные code paths в мало-мальски крупной программе становится невозможно из-за совершенно дикого количества их всевозможных сочетаний.
> Протестировать все возможные code paths в мало-мальски крупной программе становится невозможно из-за совершенно дикого количества их всевозможных сочетаний.Протестировав все возможные входа юнитов, а это вполне реально, автоматом покрываются все code path, нэ?
Все возможные пути протестировать нельзя, иначе задача об остановке программы была бы разрешима. Возможный подход к полному покрытию - model checking, тем не менее обычно происходит "взрыв" числа состояний, и о применимости к "каждодневному программированию" говорить не приходится.
Другой вариант - статический анализ, верификация. Там от контрактов деваться практически некуда, т.к. на сегодняшний момент инструментарий не настолько силён, чтобы что-то выводить без подсказок.
> Все возможные пути протестировать нельзя, иначе задача об остановке программы была бы
> разрешима. Возможный подход к полному покрытию - model checking, тем не
> менее обычно происходит "взрыв" числа состояний, и о применимости к "каждодневному
> программированию" говорить не приходится.
> Другой вариант - статический анализ, верификация. Там от контрактов деваться практически
> некуда, т.к. на сегодняшний момент инструментарий не настолько силён, чтобы что-то
> выводить без подсказок.code coverage и задача об остановке никак не связаны.
Так ведь code coverage ничего и не гарантирует. Мы можем лишь убедиться, что определённые (все) участки программы достижимы, и на определённых данных вычисляют определённые результаты.
Контракты никак не отменяют юнит-тесты. Но они позволяют реализовывать дополнительные модели тестирования. То, что сейчас поддерживается в EiffelStudio - возможность автоматически генерировать тесты на основе а) выполнения программы, приводящей к нештатной ситуации; б) вызову отдельных компонентов с сгенерированными входными данными, приводящему к нештатной ситуации. В обоих случаях под нештатной ситуацией понимается нарушение контракта или исключение.
Внезапно, я не противопоставляю контракты и юниттесты. Хотя, ассерты на стероидах, как и сам эйфель просто не нужны.
>Внезапно, я не противопоставляю контракты и юниттесты.Они и не противопоставляются, применение контрактов не означает полного отказа от юниттестов, но позволяет существенно уменьшить их количество.
>ассерты на стероидах
Контракты вовсе не являются ассертами на стероидах
>как и сам эйфель просто не нужны.
Обоснование ненужности будет или просто неаргументированная ненависть?
Безусловно, существует много ненужных вещей. Вопрос лишь в контексте, о котором идёт речь. По нелепой случайности Хоар популяризовал свои тройки настолько, что все системы верификации помимо остальных механизмов до сих пор используют их. В виде предусловий, постусловий и инвариантов класса. Видимо, так же по недосмотру всё ещё используются инварианты и варианты циклов.
Но раз есть гораздо лучшая замена, буду раз узнать.
Несчастные юнит-тесты. В последнее время про них всё время норовят всякую чушь написать.Что значит поддерживать юнит-тесты в актуальном состоянии? И почему их вдруг стало трудно писать?
Если три-четыре строчки юнит-теста вызывают проблемы, то может вообще не стоит браться разрабатывать приложения? Тем более на Eiffel...
Да там просто идиотскую аннотацию написали. Сама дока вполне достойная, как и контракты в целом.
Аннотация обновлена.