我们在一个相当大的应用程序中非常成功地使用Simple Injector。我们对所有生产类都使用构造函数注入，并配置Simple Injector来填充所有内容，一切都很顺利。
然而，在单元测试中，我们没有使用Simple Injector管理依赖关系树。相反，我们手动创建了所有对象。
我花了几天时间进行了一次重大的重构，几乎所有的时间都用来修复我们在单元测试中手动构建的依赖关系树。
这让我想知道 - 是否有人有任何模式可以用来配置他们在单元测试中使用的依赖关系树？对于我们来说，至少在测试中，我们的依赖关系树往往相当简单，但是它们很多。
有人有什么方法来管理这些吗？
对于真正的单元测试（即只测试一个类并模拟其所有依赖关系的测试），使用DI框架是没有任何意义的。在这些测试中：
Setup()代码。这样，您每个测试类仅会出现一个new PersonController(...)语句。var person = new PersonBuilder().Build()，可能还需要一些链接方法调用来获取测试中特定关注的数据部分。您也可能会对AutoFixture感兴趣，但我从未使用过，因此无法保证它。如果您正在编写需要测试系统的几个部分之间交互的集成测试，但仍需要能够模拟特定部分，那么请考虑为您的服务创建构建器类，以便您可以这样说，例如var personController = new PersonControllerBuilder.WithRealDatabase(connection).WithAuthorization(new AllowAllAuthorizationService()).Build()。
如果您正在编写端到端或“场景”测试，需要测试整个系统，则有意义设置DI框架，利用与实际产品使用的相同配置代码。您仍然可以利用您创建的其他构建器类来构建数据。
var user = new PersonBuilder().Build();
using(Login.As(user))
{
var controller = Container.Get<PersonController>();
var result = controller.GetCurrentUser();
Assert.AreEqual(result.Username, user.Username)
}
EmailService），但尽可能接近真实情况。在这种情况下，您通常会使用容器来解析整个对象图。private ClassUnderTest CreateClassUnderTest(
ILogger logger = null,
IMailSender mailSender = null,
IEventPublisher publisher = null)
{
return new ClassUnderTest(
logger ?? new FakeLogger(),
mailSender ?? new FakeMailer(),
publisher ?? new FakePublisher());
}
public void Doing_something_will_always_log_a_message()
{
// Arrange
var logger = new ListLogger();
ClassUnderTest sut = CreateClassUnderTest(logger: logger);
// Act
sut.DoSomething();
// Arrange
Assert.IsTrue(logger.Count > 0);
}