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

发表于:2014-05-27来源:外刊It评论作者:不详点击数: 标签:测试驱动开发
18. productView, 19. navigationService, 20. productService, 21. basketService); 22. 23. // Act 24. productPresenter.Initialize(); 25. 26. // Assert 27. Assert.IsNotNull(productView.Product); 28. Asser

  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/