Как объединить методы защитного программирования вместе?

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

Ну, я хочу увеличить уровень кода, который я создаю. Теперь я в основном использую TDD и статический анализ кода, чтобы убедиться, что мой код верен. Недавно я слушал речь Дино Эспозито о кодовых контрактах, и теперь я хочу использовать ее в сочетании с другими методами. Слушая Дино, я также вспомнил Debug.Assert() и Trace.Assert().

Чтобы быть конкретным, я задам несколько вопросов:

Как мне написать контракты и модульные тесты, чтобы они дополняли друг друга?
Должен ли я использовать кодовые контракты в каждом методе или только в общедоступных методах?
Должен ли я предотвратить использование Debug.Assert()? Когда это ОК, чтобы использовать их? (Например, обратите внимание, что инварианты в .net проверяются только на выходе public method/property. Итак, можно ли сделать некоторые проверки в середине метода простым Assert()?)
Не могли бы вы порекомендовать мне проект с открытым исходным кодом, в котором все эти методы будут правильно использоваться, потому что картинка рисует тысячу слов?

Ответ 1

Вы должны начать с изучения (довольно хорошего) руководства для Контрактов.

у него есть глава и пример кода об интеграции unit test. Гораздо больше информации, если вы следуете ссылкам Pex.
всегда использовать контракты для всех публичных участников. Частным членам: иногда.
вы все равно можете использовать Debug.Assert(), но Contracts.Assert() будет более логичным выбором.
Примеры проектов... Не знаю. Но посмотрите на контракты, определенные для BCL.

Ответ 2

Я бы полностью принял контракты, как в блогах предварительного просмотра, и прочитал более длинный pdf-документ.

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

В ваших тестовых примерах функций будет проверена всякая логика, которая еще нуждается в тестировании в функции после того, как Контракт pre/post и инвариантные вызовы выполняют свою работу.

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

Убедитесь, что ваши сгенерированные документы включают ваши контракты, и это выгодно.

Мне также нравится DevExpress CodeRush и Refactor! Pro. У них есть конкретные рефакторинги для Контрактов, такие как пара кликов, чтобы включить входные параметры в требуемые контракты и т.д. Кроме того, у них есть хороший анализ кода, который в целом повысит качество вашего кода.

Вы можете заглянуть в код с Контрактами здесь: https://searchcode.com/codesearch/view/14318515/

Что касается всей лучшей практики энчилада в одном проекте. Ну, я смотрю на тебя, Microsoft. Tsk.

Хенк отлично справился с остальными вашими вопросами.