Потоковое видео с фрагментированных данных на конечную точку на сервере Node

Для истинных модульных тестов (т. е. те, которые проверяют только один класс и издеваются над всеми его зависимостями), нет смысла использовать структуру DI. В этих тестах:

• , если вы обнаружите, что у вас есть много повторяющихся кодов для new, используя экземпляр вашего класса со всеми созданными вами mocks, одна полезная стратегия - создайте все свои mocks и создайте экземпляр для субъекта-теста в вашем методе установки (все это могут быть частные поля экземпляра), а затем область «организовать» каждого отдельного теста просто должна вызвать соответствующий код Setup() на методы, которые он должен издеваться. Таким образом, вы получаете только один оператор new PersonController(...) для каждого тестового класса.
• , если вам нужно создать много объектов домена / данных, полезно создавать объекты Builder, которые начинаются со здравых значений для тестирования. Поэтому вместо того, чтобы ссылаться на огромный конструктор по всему вашему коду с кучей поддельных значений, вы в основном просто вызываете, например, var person = new PersonBuilder().Build(), возможно, с помощью нескольких цепочек вызовов для фрагментов данных, которые вам особенно интересны в этот тест. Вы также можете быть заинтересованы в AutoFixture , но я никогда не использовал его, поэтому я не могу ручаться за него.

Если вы пишете Integration , где вам нужно протестировать взаимодействие между несколькими частями системы, но вы все равно должны иметь возможность издеваться над определенными частями, подумайте о создании классов Builder для своих служб, чтобы вы могли сказать, например var personController = new PersonControllerBuilder.WithRealDatabase(connection).WithAuthorization(new AllowAllAuthorizationService()).Build().

Если вы пишете сквозные или «сценарийные» тесты, где вам нужно протестировать всю систему, тогда имеет смысл настроить вашу инфраструктуру DI, используя тот же код конфигурации, который использует ваш реальный продукт. Вы можете немного изменить конфигурацию, чтобы обеспечить себе лучший программный контроль над такими вещами, как пользователь, который входит в систему и т. Д. Вы также можете использовать другие классы строителей, которые вы создали для создания данных.

var user = new PersonBuilder().Build();
using(Login.As(user))
{
     var controller = Container.Get();
     var result = controller.GetCurrentUser();
     Assert.AreEqual(result.Username, user.Username)
}