Стабы и моки нарушают инкапсуляцию / Comments / Habr

MountainGoat Jul 23 at 13:47

Недавно я понял, что проблема с моками и стабами заключается в том, что они нарушают инкапсуляцию.

Как - то отсутствует объяснение того, почему соблюдение инкапсуляции в тестах - это ценность.

Gorthauer87 Jul 23 at 23:09

Потому что тогда тесты тестируют детали реализации, а не внешне поведение и контракты в целом.

michael_v89 Jul 24 at 09:14

Созданное значение должно быть равно полученному
Если подвергнуть динамический мок тому же тесту, как он себя поведёт?

Такой тест может быть только интеграционным. Похоже, автор совершенно не разбирается в вопросе.

var sut = new Mock<IReservationsRepository>().Object;
 
await sut.Create(restaurantId, expected);
var actual = await sut.ReadReservation(restaurantId, expected.Id);

В юнит-тестах мокать нужно зависимости тестируемого юнита, а автор тут мокает сам юнит.

var sut = new FakeDatabase();
 
await sut.Create(restaurantId, expected);
var actual = await sut.ReadReservation(restaurantId, expected.Id);

"Классы SqlReservationsRepository и FakeDatabase ведут себя в соответствии с контрактом"

Прохождение теста с FakeDatabase никак не гарантирует, что SqlReservationsRepository будет работать так же. Тестирование фейков тут ничем не отличается от тестирования моков, этот тест не имеет смысла.

var sut = new ReservationsController();
await sut.Post(expected.ToDto());

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

aaoo Jul 24 at 10:27

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