Могут ли быть созданы настройки автофиксатора (через атрибуты NUnit3) и если да, то как? - PullRequest
Новая
       53

Могут ли быть созданы настройки автофиксатора (через атрибуты NUnit3) и если да, то как?

0 голосов
/ 05 марта 2020

Я работаю над некоторыми тестами, в которых я хотел бы создать логику настройки объекта c, которая инкапсулирована в классы настройки Autofixture. Вот соответствующие части того, что у меня есть: 

public class UseSpecificConstructorCustomization : ICustomization
{
    public void Customize(IFixture fixture) 
    {
        fixture.Customize<MyObject>(c => c.FromFactory((string s) => new MyObject(s)));
    }
}

public class ExecuteMethodCustomization : ICustomization
{
    public void Customize(IFixture fixture) 
    {
        fixture.Customize<MyObject>(c => c.Do(x => x.AMethodIWantToExecute()));
    }
}

Для каждой из этих настроек у меня есть соответствующая реализация CusomizeAttribute, которая возвращает экземпляр настройки. Теперь в моем тесте (NUnit3.x) я хотел бы сделать что-то вроде этого: 

[Test,AutoData]
public void ThisIsMyTestMethod([UseSpecificConstructor,ExecuteMethod] MyObject obj)
{
    // Here I would like the object to have been created using the specified
    // string constructor AND the method 'AMethodIWantToExecute' to have been executed.
}

Поведение, которое я наблюдаю, предполагает, что в этом случае только одна из двух настроек used - кажется, в зависимости от того, что указано последним. Это имеет какой-то смысл, потому что Autofixture - это «создание» объектов, а не их изменение после их создания. Не имеет смысла иметь две настройки (которые внутренне соответствуют создателям образцов), которые будут использоваться для создания одного и того же объекта.

Есть ли способ, используя Autofixture, достичь того, что я описал? Я предполагаю, что мне нужен механизм, похожий на настройку, который не использует конструктор образцов, а вместо этого предоставляет «настройщик образцов» для последующей обработки объекта после того, как конструктор образцов выполнил свою работу. Такой механизм сможет только установить свойства и использовать .Do() (не .FromFactory() et c). Если он не существует, я могу go и запросить функцию, но, возможно, он существует, и я его не вижу.

Я понимаю, что я мог бы альтернативно переместить эту "конфигурацию объекта после создания "logi c в самом тесте, но он длиннее нескольких строк, и я бы не стал его дублировать. Кроме того - эта логика установки c не имеет особого отношения к тесту, она просто переводит объект в базовое c допустимое состояние. «Познавательно», что logi c принадлежит логике создания объекта; IE: разработчик не хочет думать об этом.

1 Ответ

0 голосов
/ 06 марта 2020

Проведя еще несколько исследований / изучая мой собственный исходный код, я думаю, что нашел ответ. Решение заключается в фиксаторах поведения .

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

Поведения добавляются / удаляются в / из прибора с помощью fixture.Behaviors.

То, что я вижу сам, - это преобразование многих моих классов NUnit3 / Autofixture CustomizeAttribute для добавления поведения в прибор вместо добавления компоновщиков образцов. Таким образом, я могу составить два или три атрибута для одного и того же параметра теста, чтобы получить желаемый результат.

...