1.1, Crazy Alex (ok), 02:23, 11/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Я так понимаю, аннотация не с английского переводилась? Потому что в ней, простите, чушь написана.
Контракты и юниттесты - заимно дополняющие друг друга технологии. Хотя бы потому, что контракты проверяются только на том code path, по которому пошло исполнение программы, а юниттесты позволяют прогнать (в идеале) каждый code path (и, в том числе, осбеспечить проверку контрактов при этом).
| |
|
2.2, Аноним (-), 02:51, 11/03/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
> юниттесты позволяют прогнать (в идеале) каждый code path
Юнит-тесты позволяют протестировать валидность поведения кусочков программы ("юнитов"). Протестировать все возможные code paths в мало-мальски крупной программе становится невозможно из-за совершенно дикого количества их всевозможных сочетаний.
| |
|
3.3, Аноним (-), 09:38, 11/03/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> Протестировать все возможные code paths в мало-мальски крупной программе становится невозможно из-за совершенно дикого количества их всевозможных сочетаний.
Протестировав все возможные входа юнитов, а это вполне реально, автоматом покрываются все code path, нэ?
| |
|
4.4, Александр (??), 12:41, 11/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
Все возможные пути протестировать нельзя, иначе задача об остановке программы была бы разрешима. Возможный подход к полному покрытию - model checking, тем не менее обычно происходит "взрыв" числа состояний, и о применимости к "каждодневному программированию" говорить не приходится.
Другой вариант - статический анализ, верификация. Там от контрактов деваться практически некуда, т.к. на сегодняшний момент инструментарий не настолько силён, чтобы что-то выводить без подсказок.
| |
|
5.5, Аноним (-), 12:49, 11/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Все возможные пути протестировать нельзя, иначе задача об остановке программы была бы
> разрешима. Возможный подход к полному покрытию - model checking, тем не
> менее обычно происходит "взрыв" числа состояний, и о применимости к "каждодневному
> программированию" говорить не приходится.
> Другой вариант - статический анализ, верификация. Там от контрактов деваться практически
> некуда, т.к. на сегодняшний момент инструментарий не настолько силён, чтобы что-то
> выводить без подсказок.
code coverage и задача об остановке никак не связаны.
| |
|
6.6, Александр (??), 13:29, 11/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
Так ведь code coverage ничего и не гарантирует. Мы можем лишь убедиться, что определённые (все) участки программы достижимы, и на определённых данных вычисляют определённые результаты.
Контракты никак не отменяют юнит-тесты. Но они позволяют реализовывать дополнительные модели тестирования. То, что сейчас поддерживается в EiffelStudio - возможность автоматически генерировать тесты на основе а) выполнения программы, приводящей к нештатной ситуации; б) вызову отдельных компонентов с сгенерированными входными данными, приводящему к нештатной ситуации. В обоих случаях под нештатной ситуацией понимается нарушение контракта или исключение.
| |
|
7.7, Аноним (-), 15:57, 11/03/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
Внезапно, я не противопоставляю контракты и юниттесты. Хотя, ассерты на стероидах, как и сам эйфель просто не нужны.
| |
|
8.8, croster (ok), 16:42, 11/03/2013 [^] [^^] [^^^] [ответить] | +1 +/– | Они и не противопоставляются, применение контрактов не означает полного отказа о... текст свёрнут, показать | |
|
|
|
|
|
|
|
1.10, northbear (??), 21:20, 11/03/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Несчастные юнит-тесты. В последнее время про них всё время норовят всякую чушь написать.
Что значит поддерживать юнит-тесты в актуальном состоянии? И почему их вдруг стало трудно писать?
Если три-четыре строчки юнит-теста вызывают проблемы, то может вообще не стоит браться разрабатывать приложения? Тем более на Eiffel...
| |
|
2.11, Crazy Alex (ok), 21:43, 11/03/2013 [^] [^^] [^^^] [ответить]
| +/– |
Да там просто идиотскую аннотацию написали. Сама дока вполне достойная, как и контракты в целом.
| |
|
|