理解为什么我们在单元测试中使用控制反转容器

我目前正在研究将Ninject集成到我的单元测试中。通过阅读一些与早期问题相关的非常聪明的帖子（Ninject是什么，什么时候使用它？，http://martinfowler.com/articles/injection.html）;我认为我理解了一些核心概念，但我对其中一些应用还有困惑。\n大多数情况下，当提到IOC容器时，是在将它们纳入到您的单元测试中。然而，从实际角度来看，如果我还没有将它纳入到我的实际代码库中，使用像Ninject这样的框架在我的单元测试中是否有意义？\n以下是一个例子（摘自James Bender的《使用C#进行专业测试驱动开发：用TDD开发实际应用程序》）：\n

[TestFixture]
public class PersonServiceTests
{
    [Test]
    public void ShouldBeAbleToCallPersonServiceAndGetPerson()
    {
        var expected = new Person {Id = 1, FirstName = “John”, LastName = “Doe”};
        var kernel = new StandardKernel(new CoreModule());
        var personService = kernel.Get < PersonService > ();
        var actual = personService.GetPerson(expected.Id);
        Assert.AreEqual(expected.Id, actual.Id);
        Assert.AreEqual(expected.FirstName, actual.FirstName);
        Assert.AreEqual(expected.LastName, actual.LastName);
    }
}

\n使用Ninject编写我的测试如何改善我的生活（或任何继承我的代码的开发人员），而不是只是像这样编写我的测试：\n

[TestFixture]
public class PersonServiceTests
{
    [Test]
    public void ShouldBeAbleToCallPersonServiceAndGetPerson()
    {
        var expected = new Person {Id = 1, FirstName = “John”, LastName = “Doe”};
        var personService = new PersonService();
        var actual = personService.GetPerson(expected.Id);
        Assert.AreEqual(expected.Id, actual.Id);
        Assert.AreEqual(expected.FirstName, actual.FirstName);
        Assert.AreEqual(expected.LastName, actual.LastName);
    }
}

\n随着我将依赖反转原则引入到我的代码中，我看到了使用IOC容器的价值，它可以减少与我的类实例化方式相关的冗余/集中代码（作为遵守依赖反转原则的结果）。然而，如果我不使用IOC容器来编写代码，使用类似Ninject这样的框架作为我的单元测试框架是否实际？