https://www.opennet.me/openforum/vsluhforumID3/89035.html Выполнен (http://www.opennet.ru/base/dev/DesignByContract.txt.html) перевод на русский язык документации Eiffel по технологии проектирования по контракту (Design by Contract).<br><br><br><br>Широко распространенным способом тестирования программных<br> компонент является выполнение юнит-тестов. Юнит-тесты описывают набор<br> шагов, которые необходимо выполнить, для получения необходимого<br> результата. Однако юнит-тесты трудно писать и поддерживать в актуальном<br> состоянии, отсутствие декларативности и интеграции в код затрудняет<br> понимание спецификации программного компонента, объём кода юнит-тестов,<br> как правило, достаточно велик. Этих недостатков лишены контракты,<br> которые накладывают ограничения и обязательства на компоненты класса.<br> Контракты являются частью документации программной системы, позволяют<br> легко тестировать отдельные компоненты, упрощают повторное<br> использование и отладку. <br><br><br>Проектирование по контракту изначально<br> поддерживается в языке Eiffel как на уровне инструментов ср https://www.opennet.me/openforum/vsluhforumID3/89035.html#12 Tue, 19 Mar 2013 04:13:48 GMT Аннотация обновлена.<br> https://www.opennet.me/openforum/vsluhforumID3/89035.html#11 Mon, 11 Mar 2013 17:43:02 GMT Да там просто идиотскую аннотацию написали. Сама дока вполне достойная, как и контракты в целом.<br> https://www.opennet.me/openforum/vsluhforumID3/89035.html#10 Mon, 11 Mar 2013 17:20:15 GMT Несчастные юнит-тесты. В последнее время про них всё время норовят всякую чушь написать.<br><br>Что значит поддерживать юнит-тесты в актуальном состоянии? И почему их вдруг стало трудно писать? <br>Если три-четыре строчки юнит-теста вызывают проблемы, то может вообще не стоит браться разрабатывать приложения? Тем более на Eiffel... <br> https://www.opennet.me/openforum/vsluhforumID3/89035.html#9 Mon, 11 Mar 2013 13:17:11 GMT Безусловно, существует много ненужных вещей. Вопрос лишь в контексте, о котором идёт речь. По нелепой случайности Хоар популяризовал свои тройки настолько, что все системы верификации помимо остальных механизмов до сих пор используют их. В виде предусловий, постусловий и инвариантов класса. Видимо, так же по недосмотру всё ещё используются инварианты и варианты циклов.<br>Но раз есть гораздо лучшая замена, буду раз узнать.<br> https://www.opennet.me/openforum/vsluhforumID3/89035.html#8 Mon, 11 Mar 2013 12:42:45 GMT &gt;Внезапно, я не противопоставляю контракты и юниттесты.<br><br>Они и не противопоставляются, применение контрактов не означает полного отказа от юниттестов, но позволяет существенно уменьшить их количество.<br><br>&gt;ассерты на стероидах<br><br>Контракты вовсе не являются ассертами на стероидах<br><br>&gt;как и сам эйфель просто не нужны.<br><br>Обоснование ненужности будет или просто неаргументированная ненависть?<br> https://www.opennet.me/openforum/vsluhforumID3/89035.html#7 Mon, 11 Mar 2013 11:57:50 GMT Внезапно, я не противопоставляю контракты и юниттесты. Хотя, ассерты на стероидах, как и сам эйфель просто не нужны.<br> https://www.opennet.me/openforum/vsluhforumID3/89035.html#6 Mon, 11 Mar 2013 09:29:51 GMT Так ведь code coverage ничего и не гарантирует. Мы можем лишь убедиться, что определённые (все) участки программы достижимы, и на определённых данных вычисляют определённые результаты.<br>Контракты никак не отменяют юнит-тесты. Но они позволяют реализовывать дополнительные модели тестирования. То, что сейчас поддерживается в EiffelStudio - возможность автоматически генерировать тесты на основе а) выполнения программы, приводящей к нештатной ситуации; б) вызову отдельных компонентов с сгенерированными входными данными, приводящему к нештатной ситуации. В обоих случаях под нештатной ситуацией понимается нарушение контракта или исключение.<br> https://www.opennet.me/openforum/vsluhforumID3/89035.html#5 Mon, 11 Mar 2013 08:49:17 GMT &gt; Все возможные пути протестировать нельзя, иначе задача об остановке программы была бы <br>&gt; разрешима. Возможный подход к полному покрытию - model checking, тем не <br>&gt; менее обычно происходит "взрыв" числа состояний, и о применимости к "каждодневному <br>&gt; программированию" говорить не приходится.<br>&gt; Другой вариант - статический анализ, верификация. Там от контрактов деваться практически <br>&gt; некуда, т.к. на сегодняшний момент инструментарий не настолько силён, чтобы что-то <br>&gt; выводить без подсказок.<br><br>code coverage и задача об остановке никак не связаны.<br> https://www.opennet.me/openforum/vsluhforumID3/89035.html#4 Mon, 11 Mar 2013 08:41:10 GMT Все возможные пути протестировать нельзя, иначе задача об остановке программы была бы разрешима. Возможный подход к полному покрытию - model checking, тем не менее обычно происходит "взрыв" числа состояний, и о применимости к "каждодневному программированию" говорить не приходится.<br>Другой вариант - статический анализ, верификация. Там от контрактов деваться практически некуда, т.к. на сегодняшний момент инструментарий не настолько силён, чтобы что-то выводить без подсказок.<br>