Autofixture: Замораживание макета не отменяет внедренный экземпляр

Привет @ charles-salmon,

Спасибо, что нашли время сообщить об этом.

Наблюдаемое вами поведение - это дизайн. Позвольте мне объяснить. 🙂

Если вы посмотрите на реализацию метода Freeze<T> :

var value = fixture.Create<T>();
fixture.Inject(value);
return value;

Вы увидите, что все, что он делает, это создает образец T и вводит его в приспособление. Действительно, метод Freeze стал удобным ярлыком для этой самой операции. Как написал @ploeh в своем посте, рассказывающем о методе Freeze еще в 2010 году:

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

Учитывая это, неудивительно, что замораживание того же типа T что и внедренный экземпляр, дает тот же экземпляр.

Теперь, чтобы обратиться к вашей точке зрения:

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

Учитывая, что прибор представляет _контекст_, в котором выполняется тест, вы, безусловно, _можете_ иметь несколько тестов, совместно использующих одно и то же приспособление ; однако это происходит за счет смешения множества - и, возможно, противоречивых - проблем.

Книга xUnit Patterns прекрасно резюмирует :

Самая большая проблема с Shared Fixture заключается в том, что это может привести к «конфликтам» между тестами, что может привести к ошибочным тестам , поскольку тесты могут зависеть от результатов других тестов. Другая проблема заключается в том, что приспособление, предназначенное для обслуживания множества тестов, обязательно будет намного сложнее, чем минимальное приспособление, необходимое для одного теста.

Эта «коллизия» - именно то, что происходит, когда тест ожидает, что объект типа T будет конкретным экземпляром, в то время как другой тест ожидает, что T будет поддельным объектом .

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