Используя инструменты Code Contracts, доступные в VS2010 Beta 2, я определил интерфейс, класс контракта для этого интерфейса и два класса, которые реализуют интерфейс.
Теперь, когда я приду к тесту кода, я хочу протестировать классы реализации, чтобы я знал, что их функциональные возможности верны, и я хочу проверить код контракта, чтобы я знал, что мои условия верны.
Я мог бы протестировать каждый оператор контракта в каждом из 2 классов реализации, но это явно избыточно. Я мог бы просто написать тесты для одного из этих классов реализации, но это кажется немного неправильным, как выбирать между ними, помнить, какой из них обновлять при изменении контрактов и т. Д.
Я хотел бы протестировать фактический класс контракта интерфейса, но получить всевозможные предупреждения времени компиляции о том, что метод интерфейса, который я хочу протестировать, недоступен в классе контракта интерфейса. Я знаю, что происходит волшебство после компиляции, которое фактически внедряет код контракта в мои классы реализации (что я вижу в ILDASM), но когда я проверяю методы класса контрактного интерфейса, они присутствуют в MISL, но пустые.
Я что-то упустил или то, что я хочу сделать, просто невозможно. Если это не так, какова «лучшая практика» для этого?
=== Редактирование ===
Одно из предложений здесь состоит в том, чтобы реализовать интерфейс в классе (внутреннем для тестовой сборки), целью которого является исключительно тестирование интерфейсов, звучит разумно?