Модель предметной области (раскрытие общедоступных свойств)

Question

Итак, при построении модели предметной области я стараюсь прагматично демонстрировать только то, что необходимо для управления поведением, но мои модульные тесты требуют, чтобы я выставлял общедоступные методы получения, которые действительно нужны только внутри класса.как все справляются с этим?доступ к слою моего домена возможен только через уровень служб приложений, поэтому действительно ли это важно для ?я должен сделать их внутренними и дать доступ к тестовому проекту?

любая помощь будет отличной!

Answer 1

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

Если вам необходимо получить доступ к внутреннему состоянию объекта, чтобы проверить его, я бы создал несколько методов расширения в своем пространстве имен тестирования, которые обеспечивают легкий доступ к частным свойствам объекта (например, T GetPropertyValueByName (эта строка propertyName).

Answer 2

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

Answer 3

Я согласен с утверждением Эрика о том, что модульные тесты не должны влиять на API классов.

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

Либо разделите ваши объекты так, чтобы частные поля были открыты на каком-то слое (делая объекты более детализированными), либо измените ваши тесты, чтобы не нуждаться в доступе к этим закрытым полям (делая ваши юнит-тесты более грубыми) .

Одним из полезных инструментов является Кодовые контракты. Вы можете определять очень мелкозернистые тесты (постусловия и объектные инварианты, определенные в терминах частных полей), используя кодовые контракты, и сделать ваше модульное тестирование немного более крупнозернистый. Некоторые из моих модульных тестов делают только вызов метода и гарантируют, что кодовые контракты не сработают.

Answer 4

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