在单元测试的上下文中,可以创建两个控制器构造函数,默认情况下,控制器工厂将使用该构造,另一个用于单元测试。
public class ProductController : Controller
{
private IProductRepository repository;
public int PageSize = 10;
// default constructor
public ProductController()
{
this.repository = new ProductRepository();
}
// dedicated for unit testing
public ProductController(IProductRepository productRepository)
{
this.repository = productRepository;
}
public ViewResult List(int page=1)
{
return View(repository.Products
.OrderBy(p => p.ProductID)
.Skip((page - 1) * PageSize)
.Take(PageSize));
}
}
可以通过这种方式实现单元测试
[TestMethod]
public void Can_Paginate()
{
// Arrange
Mock<IProductRepository> mock = new Mock<IProductRepository>();
mock.Setup(m => m.Products).Returns(new Product[]
{
new Product {ProductID = 1, Name = "P1"},
new Product {ProductID = 2, Name = "P2"},
new Product {ProductID = 3, Name = "P3"},
new Product {ProductID = 4, Name = "P4"},
new Product {ProductID = 5, Name = "P5"}
}.AsQueryable());
ProductController controller = new ProductController(mock.Object);
controller.PageSize = 3;
// Act
IEnumerable<Product> result =
(IEnumerable<Product>)controller.List(2).Model;
// Assert
Product[] prodArray = result.ToArray();
Assert.IsTrue(prodArray.Length == 2);
Assert.AreEqual(prodArray[0].Name, "P4");
Assert.AreEqual(prodArray[1].Name, "P5");
}
在上面我能够实现单元测试。我的问题是,如果我可以使用专用的构造函数实现DI,为什么我会选择使用DI框架(例如Unity,ninight等)?我必须在这里缺少明显的东西。
(顺便说一句,上面的代码样本主要来自亚当·弗里曼(Adam Freeman)的书ASP.NET MVC 4书,我对其进行了一些修改以适合我需要提出的问题)
在这个微不足道的例子中。从技术上讲,没有理由。
框架的重点是在全球管理依赖项及其存在的各个部分……而不仅仅是注入依赖。终身/范围,如何/何时,在哪里/为什么。您在这里拥有的仍然紧密地耦合到ProductRepository
...
在复杂的应用程序中,您目前需要这样的东西:
this.repository = new ProductRepository(
new ShoppingCartRepository(
new Logger()),
new ReviewsRepository(
new Logger()),
new Logger());
..尽管使用DI/IOC框架,您不必担心任何一个基础和所有基础的生命周期/连接逻辑。