В TDD и DDD, как вы обрабатываете свойства только для чтения в подделках?

Question

Вопрос

Как вы обрабатываете поля только для чтения при создании подделок?

фон

Я в начинающих этапах с помощью ASP.Net MVC, и я с помощью спортивного магазина Стивена Сандерсона и Nerd ужина Скотта Гу в качестве примеров. Одна небольшая проблема, с которой я только что столкнулась, заключается в том, как работать с свойствами только для чтения при создании подделок. Я использую LINQToSQL.

Мой интерфейс:

public interface IPersonRespository 
{ 
    Person GetPerson(int id); 
} 

и моя подделка становится

public class FakePersonRepository 
{ 
    public Person GetPerson(int id) 
    { 
     return new Person {id="EMP12345", name="John Doe", age=47, ssn=123-45-6789, totalDrWhoEpisodesWatched=42}; 
    } 
} 

Вот моя проблема. Поля id, ssn и totalDrWhoEpisodesWatched доступны только для чтения, поэтому приведенный выше код фактически не работает. Однако я не понимаю, как создать поддельного нового человека и установить свойство только для чтения. Я уверен, что есть решение, но я еще не встречал его в своих поисках.

Обновление: Наследование + Скрытие собственности как потенциальное решение?

Я еще не решил решительного решения проблемы. Мне не нравится понятие модификации моих классов домена для создания подделок. Для меня добавление разметки к классам домена для проведения тестирования - это форма добавленной связи - к реализации вашего теста. Теперь я изучаю еще одну возможность, которая заключается в создании класса FakePerson, который наследуется от Person, но скрывает свойства с новыми свойствами read-write.

public class FakePerson: Person 
{ 
    public new int age { get; set; } 
    public new string ssn { get; set; } 
    public new int totalDrWhoEpisodesWatched { get; set; } 
} 

До сих пор это решение заключается в том, как я склоняюсь. Это нарушает Принцип замещения Лискова, однако это не влечет меня в тестовый проект. Я был бы рад услышать любую критику и/или отзывы об этом в качестве решения.

Победитель: Mock Каркасы

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

Answer 1

Рассмотрите насмешку над типом Person в своем тесте. Пример использования Moq:

var mock = new Mock<Person>(); 
mock.SetupGet(p => p.id).Returns("EMP12345"); 
mock.SetupGet(p => p.ssn).Returns("123-45-6789"); 
mock.SetupGet(p => p.totalDrWhoEpisodesWatched).Returns(42); 
return mock.Object; 

В противном случае, попробуйте выяснить, как LINQ к SQL устанавливает те только для чтения свойства.

EDIT: Если вы попытаетесь выше и Moq бросает ArgumentException в SetupGet вызов с сообщением «Invalid установки на не переопределение члена: р => p.id», то вам необходимо отметить свойство виртуальное. Это необходимо сделать для каждого свойства, которое вы хотите переопределить.

В LINQ к SQL, это может быть сделано в OR дизайнер, выбрав свойство, а затем в окне Свойства установите Наследование Модификатор в виртуальный.

Answer 2

Вы можете устанавливать только свойства readonly в конструкторе класса. Объект Person должен иметь конструктор, который принимает id, ssn и totalDrWhoEpisodesWatched. Конечно, если это объект, созданный linqtosql, у вас могут возникнуть проблемы с модификацией этого кода при автоматическом создании кода.

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

Answer 3

В .NET вы можете пометить свои сеттеры как «внутренние» и использовать атрибут сборки InternalsVisibleTo, чтобы внутренние элементы были видимыми для вашей тестовой сборки. Таким образом, ваши сеттеры не будут публичными, но вы все равно сможете получить к ним доступ.

примечание: даже если вопрос не отмечен.NET, я предположил, что он основан на использовании синтаксиса инициализатора объекта. Если мое предположение было неправильным, это предложение не применяется (если, конечно, язык, который вы используете, не имеет эквивалентной функции).

Answer 4

Если это для испытаний - подумайте об использовании отражения. Это не связано с запутыванием вашей модели домена.

Например, у меня есть класс FactoryBase, который использует отражение для установки необходимой поддержки посредством выражения лямбда через параметры (например, this). Работает как очарование - создание новой фабрики прост как определение типа репозитория и данных сущности по умолчанию.

Answer 5

Я также использую Moq. Я люблю его, и он отлично работает. Но, прежде чем я начал использовать Moq, я написал много подделок. Вот как я решил проблему, используя подделки.

Поскольку подделка может иметь дополнительные методы, которые не имеют реализации «производства», я бы добавил несколько дополнительных методов для моей поддельной реализации, чтобы обрабатывать установку только для чтения.

Как это:

public class FakePersonRepository : IPersonRespository 
{ 
    private IDictionary<int, Person> _people = new Dictionary<int, Person>(); 

    public Person GetPerson(int id) // Interface Implementation 
    { 
     return _people(id); 
    } 

    public void SetPerson(int id, Person person) // Not part of interface 
    { 
     _people.Add(id, person); 
    } 

}