测试驱动开发上的五大错误(3)

　　18. productView,

　　19. navigationService,

　　20. productService,

　　21. basketService);

　　22.

　　23. // Act

　　24. productPresenter.Initialize();

　　25.

　　26. // Assert

　　27. Assert.IsNotNull(productView.Product);

　　28. Assert.IsTrue(productView.IsInBasket);

　　29.}

　　Test #2

　　01.[TestMethod]

　　02.public void InitializeWithValidProductIDReturnsView()

　　03.{

　　04. // Arrange

　　05. var view = Mock.Create();

　　06. Mock.Arrange(() => view.ProductID).Returns("spr-product");

　　07.

　　08. var mock = new MockProductPresenter(view);

　　09.

　　10. // Act

　　11. mock.Presenter.Initialize();

　　12.

　　13. // Assert

　　14. Assert.IsNotNull(mock.Presenter.View.Product);

　　15. Assert.IsTrue(mock.Presenter.View.IsInBasket);

　　16.}

　　我相信Test #2是更容易理解的，不是吗?而Test #1的可读性不那么强的原因就是有太多的创建测试的代码。在Test #2中，我把复杂的构建测试的逻辑提取到了ProductPresenter类里，从而使测试代码可读性更强。

　　为了把这个概念说的更清楚，让我们来看看测试中引用的方法：

　　01.public void Initialize()

　　02.{

　　03. string productID = View.ProductID;

　　04. Product product = _productService.GetByID(productID);

　　05.

　　06. if (product != null)

　　07. {

　　08. View.Product = product;

　　09. View.IsInBasket = _basketService.ProductExists(productID);

　　10. }

　　11. else

　　12. {

　　13. NavigationService.GoTo("/not-found");

　　14. }

　　15.}

　　这个方法依赖于View, ProductService, BasketService and NavigationService等类，这些类都要模拟或临时构造出来。当遇到这样有太多的依赖关系时，这种需要写出准备代码的副作用就会显现出来，正如上面的例子。

　　请注意，这还只是个很保守的例子。更多的我看到的是一个类里有模拟一、二十个依赖的情况。

　　下面就是我在测试中提取出来的模拟ProductPresenter的MockProductPresenter类：

　　01.public class MockProductPresenter

　　02.{

　　03. public IBasketService BasketService { get; set; }

　　04. public IProductService ProductService { get; set; }

　　05. public ProductPresenter Presenter { get; private set; }

　　06.

　　07. public MockProductPresenter(IProductView view)

　　08. {

　　09. var productService = Mock.Create();

　　10. var navigationService = Mock.Create();

　　11. var basketService = Mock.Create();

　　12.

　　13. // Setup for private methods

　　14. Mock.Arrange(() => productService.GetByID("spr-product")).Returns(new Product());

　　15. Mock.Arrange(() => basketService.ProductExists("spr-product")).Returns(true);

　　16. Mock.Arrange(() => navigationService.GoTo("/not-found")).OccursOnce();

　　17.

　　18. Presenter = new ProductPresenter(

　　19. view,

　　20. navigationService,

　　21. productService,

　　22. basketService);

　　23. }

　　24.}

　　因为View.ProductID的属性值决定着这个方法的逻辑走向，我们向MockProductPresenter类的构造器里传入了一个模拟的View实例。这种做法保证了当产品ID改变时自动判断需要模拟的依赖。

　　我们也可以用这种方法处理测试过程中的细节动作，就像我们在第二个单元测试里的Initialize方法里处理product==null的情况：

　　01.[TestMethod]

　　02.public void InitializeWithInvalidProductIDRedirectsToNotFound()

　　03.{

　　04. // Arrange

　　05. var view = Mock.Create();

　　06. Mock.Arrange(() => view.ProductID).Returns("invalid-product");

　　07.

　　08. var mock = new MockProductPresenter(view);

　　09.

　　10. // Act

　　11. mock.Presenter.Initialize();

　　12.

　　13. // Assert

　　14. Mock.Assert(mock.Presenter.NavigationService);

　　15.}

　　这隐藏了一些ProductPresenter实现上的细节处理，测试方法的可读性是第一重要的。

原文转自：http://www.vaikan.com/top-5-tdd-mistakes/