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

Question

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

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

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

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

Answer 1

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

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

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

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

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

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

Вы можете посмотреть на некоторый кодс Контрактами здесь: https://searchcode.com/codesearch/view/14318515/

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

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

Answer 2

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

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