Тестовый шаблон Data Builder: полезнее или лучше поддерживать?

Question

Позвольте мне начать с того, что я большой поклонник элегантности этого шаблона - у меня есть группа базовых сущностей, для которых я реализовал компоновщики (специально для тестирования). Однако я обнаружил (и это, возможно, предостережение), что по мере развития моей программы мне приходилось возвращаться и пересматривать строителей. В конце концов, казалось, что не стоит обновлять их, и я вернулся к тому, чтобы в первую очередь сохранять объектную мать, которая имеет много предварительно сконфигурированных сущностей. Должен ли я продолжать обновлять компоновщики для будущего использования, или TDB должны создаваться только после того, как ваш дизайн достигнет некоторой стабильности и объектная мать станет слишком большой?

Также обратите внимание, я обнаружил, что я не использую компоновщики где-либо еще в приложении, поскольку мне нравится использовать новый синтаксис .Net 3.0 для инициализации свойств.

Answer 1

Мне нравится использовать плавные компоновщики для тестируемого объекта, чтобы выразить природу объекта, который я создаю. ObjectMothers, как правило, становятся громоздкими и имеют тенденцию (в реализациях, с которыми я сталкивался) в конечном итоге скрывать детали создания объектов.

Сравнить:

User fred = CreateUser("fred").WithReputation(900)
                              .WithScholarBadge()
                              .WithCriticBadge()

против

User fred = UserObjectMother.Fred()

Чтобы выразить идею, что у пользователя есть повтор 900, и эти два конкретных значка было бы непривычно делать с ObjectMother. Я обнаружил тенденцию, когда разработчики находят этот метод, который создает Fred(), что близко к тому, что им нужно, поэтому они добавляют больше атрибутов к объекту. Свободный конструктор, с другой стороны, выразителен в отношении того, что строится, и при необходимости легко создает конкретных пользователей для теста.

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

Answer 2

Если построители тестовых данных становятся слишком сложными для обслуживания, я бы порекомендовал перейти на среду для имитации , что делает более удобным создание тестовых объектов домена с известным состоянием.

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

Answer 3

Лямбда-синтаксис может сделать свободный интерфейс более лаконичным

Например,

User fred = new UserTestDataBuilder()
                .With(u => u.Name = "fred")
                .With(u => u.Reputation = 900)
                .With(u => u.ScholarBadge = true)
                .With(u => u.CriticBadge = true)

Для заполнения свойств вам просто необходим метод Action и класс.

public class UserSpec
{
    public string Name {get; set;}
    public int Reputation {get; set;}
    ...
}

public class UserTestDataBuilder() 
{
    private UserSpec _userSpec = new UserSpec();
    public UserTestDataBuilder With(Action<UserSpec> action) 
    {
        action(_userSpec);
        return this;
    }

    public User Build() 
    {
        return new User(_userSpec.Name, _userSpec.Reputation, _userSpec.ScholarBadge, _userSpec.CriticBadge);
    }
}