AlexanderSher
commented
9 years ago Пишу сюда же, чтобы не заводить отдельный тикет.
- Object Mother - это не просто фабричный метод, это достаточно специфичное сборище фабричных методов в одном классе. Т.е. вынесение логики инициализации в фабричный метод - это еще не Object Mother. Мне кажется, что если ты упоминаешь про новый для читателя паттерн, то надо или как-то хотя бы минимально его описать, или же обойтись уже известным читателю термином "фабричный метод".
- Вынесение инициализации в отдельные фабричные методы в общем случае не есть замена метода SetUp. Если у тебя в классе 50 тестов, и каждый из них содержит с десяток одинаковых шагов инициализации, каждый из которых возвращает нужный для теста объект, то разумно будет вынести это все в некий общий метод инициализации. Вот только туплов у нас в C# нормальных нет, а метод с 10 out-параметрами вызывает оторопь. Значит надо или заводить некий класс-контекст, или использовать поля самого класса с тестами (при условии конечно, что раннер пересоздаст нам инстанс этого класса для каждого вызова, как это делает, например, xUnit).
- Приведенный тобой пример Fixture вызывает желание выкинуть его и использовать Object Mother с дефолтными параметрами конструктора:
public static LogEntryReader CreateLogEntryReader(string content = null, ILogEntryParser parser = null)
{
parser = parser ?? new SimpleLogEntryParser();
content = content ?? string.Empty;
return LogEntryReaderTestFactory.Create(content, parser);
}Т.е. из примера не видно каких-то плюсов использования билдера. Я не знаю, можно ли что-то такое сделать именно с этим кодом. Билдер реально нужен, когда количество возможных состояний объекта условно бесконечно, и мы не можем все эти состояния представить в виде набора конструкторов (тот же FluentAssertions например). Или когда нужно изменить некое поведение объекта, например, чтобы сеттер вместо того, чтобы писать в объект, писал в переданную ему переменную, а геттер соответственно из этой переменной читал.
4.
Этот же подход позволяет спрятать в класс Fixture инициализацию моков, и выставить объект Mock<IDependency в качестве свойства.
Что такое IDependency? В главе оно вообще отсутствует.
SergeyTeplyakov
случаях - случае. Мне кажется первый вариант можно заменить на "при определенных сценариях"
ОН будет выглядеть
угловую скобку не закрыл
наверное, "читабельными", поскольку, "читаемый" - это тот, который часто или много читают
после "случаях" запятая
то же, что и выше - читабельность
Несколько вопросов по паттерну и коду: 1) Судя по коду строителя, ты позволяешь создать LogEntryReader с null аргументами, это нормально? 2) Откуда LogEntryReaderTestFactory? 3) Для меня странно название свойства Cut - это по паттерну так? 4) Ты писал о преимуществе тестовой фабрики перед использованием конструкторов в цене изменений в тестах в случае, если появится например еще один аргумент конструктора. Но в случае использования билдера эта цена снова может возрасти, так как придется менять опять все тесты. То есть я хочу сказать, что где-то в тексте возможно стоит сказать об этом случае и показать, что в билдере можно просто сделать третий аргумент с дефалтовым значением и таким образом показать, что это не одно и то же, что и использование конструкторов.