单元测试入门及实践

单元测试

   
单元测试是开发人员对其所实现功能的代码进行的另外编写的测试，用于检测其代码功能的完整性、正确性和其运行效率，从而提高代码质量，并且在写单元测试时发现功能代码间的依赖等设计问题，从而提高产品的可扩展性。

这会让开发人员费更多的时间关注于这个，在短时期来看确实是这样，但放到整个产品周期中来评估的话，其时间上来说是节约的，在后期不会陷入整个产品代码无尽的Bug状态，可以说越是在后期越能显现UT的威力，还可以更自信的交出产品。
 

目的

  
单元测试用来作用于：

  • 代码质量保证
    在开发人员修改代码后保证不会对之前、其它代码产生影响，通过简单的运行测试就可以知道当前修改会产生哪些影响（那些Failed掉的Case即是所受影响的代码）

     

  • 代码清晰、提高可维护性
    有点代码先过自己一关的味道，这样写出来的代码更优美，更具可维护性。

     

  • 使项目架构更合理
    在进行UT，可以发现代码设计中不合理的地方，提高代码的配置性，可扩展性。
 

Unit Test Framework

    
测试框架不仅提供了一整套的判断机制，还提供了运行测试用例的工具，很方便的去运行单元测试用例。

在.NET中有几个著名的测试框架，NUnit和MS Unit是其中比较火的，关于两者的对比大家可以网上找下，选择一款适合自己的，这里呢，我们使用MS Unit。

 
单元测试的方法

A sample case：

1 public int Add(int m, int n)
2 {
3     return m + n;
4 }

测试1：
在这种情况下，我们设定一个期待值，并传入两个参数进行运算，然后判断结果是不和期待值相同来进行单元测试。

1 [TestMethod]
2  public void Add_Normal_Test()
3 {
4     Calculator cal = new Calculator();
5     int expect = 3;
6 
7     int actual = cal.Add(1, 2);
8     Assert.AreEqual(expect, actual);
9 }

好的测试代码总是从多方面去进行测试，如考虑边界，错误情况下的处理...

1 [TestMethod]
2  public void Add_Error_Test()
3 {
4     Calculator cal = new Calculator();
5     int expect = 3;
6 
7     int actual = cal.Add(-3000, 2);
8     Assert.AreNotEqual(expect, actual);
9 }

 

再看下边界性况下的测试

 1 [TestMethod]
 2  public void Add_Limit_Test()
 3 {
 4     Calculator cal = new Calculator();
 5     Int64 expect = 4394967294;
 6 
 7     //// int.MaxValue = 2147483647
 8      int actual = cal.Add(int.MaxValue, int.MaxValue);
 9     Assert.AreEqual(expect, actual);
10 }

 

优化

在上面的例子中，我们在每一个Case中都去声明了Calculator对象的实例，并且都没有对该类的属性做出任何修改。那可以将其提出作为公用。并在测试类初始化时去生成Calculator的实例。

在MS Test中有两种办法在所有用例运行之前生成该依赖对象的实例：

1. 构造函数
 1 
 2 [TestClass]
 3  public class CalculatorTest
 4 {
 5     private Calculator cal;
 6 
 7     public CalculatorTest()
 8     {
 9         cal = new Calculator();
10     }
11 
12     ~CalculatorTest()
13     {
14         cal = null;
15     }
16 
17     [TestMethod]
18     public void Add_Normal_Test()
19     {
20         int expect = 3;
21 
22         int actual = cal.Add(1, 2);
23         Assert.AreEqual(expect, actual);
24     }
25 }

 


每一个类中构造函数总是第一个被执行，所以可以将对象实例化放在这里进行，同时在析构函数中对其进行删除。

 

2. ClassInitialize特性方法

[ClassInitialize()]
public static void MyClassInitialize(TestContext testContext){}

此处的用法和构造函数相似，只是这里为静态函数，要求外面所定义的变量也必须为静态。（这一点不大符合OO的习惯，更多时间我偏向用构造函数的方式）其对应的也有一个方法，在所有的用例执行完才去执行 [ClassCleanup()]

每个方法前执行的函数
  
如果方法中改变了对象的属性，那就不适合该场景，但确又每个Case都用到该对象怎么办，有一种能在每个方法前去执行的函数吗？Of Course：

[TestInitialize()]
public void MyTestInitialize(){}
该特性方法会在每个单元测试用例运行之行启动，用作于初始化一些对象，它对应的[TestCleanup()]特性方法则是用于在每个Case结束后进行的操作，有点像AOP的理念。

  
解除依赖

    
在刚才的代码中我们讲了怎么去基于一个函数去写UT，怎么写出更好的UT，为了让学习起来更简单，我们的示例代码也足够简洁。但事实上你直正写测试时不会碰到这样的代码。
你更多时会遇到这样的代码：

 1 public class UserService
 2 {
 3     public string GetUserNameById(string id)
 4     {
 5         IUserRepository userRepository = new UserRepository();
 6         User user = userRepository.GetUser(id);
 7 
 8         return user.Name;
 9     }
10 }

在方法中调用另外一个对象的方法去取得数据，那怎么去测试？

 

Q: 直接写一个对应的单元测试用例，传入一个id看返回值是否为我们想要。
A: 这种方法不可取，试想，如果用例失败，无法判断是哪一个函数出错，UserService.GetUserNameById() 本身还是UserRepository.GetUser()。同时，如果连接测试数据库，还要保证测试数据的有效性，所以这样的测试不好。

Q: 怎么写出好的测试用例？
A: 使用Mock，我们将对IUserRepository 接口进行另一个实现，在该实现中返回指定的值，从而使GetUserNameById方法的测试不依赖于UserRepository对象。

在进行Mock时我们发现，IUserRepository 放在方法中，无法在对象以外进行配置，可扩展性不强，于是我们将其提取为字段，并通过构造函数来进行赋值。

 1 public class UserService
 2 {
 3     public IUserRepository userRepository;
 4 
 5     public UserService(IUserRepository userRepository)
 6     {
 7         this.userRepository = userRepository;
 8     }
 9 
10     public string GetUserNameById(string id)
11     {
12         
13         User user = userRepository.GetUser(id);
14 
15         return user.Name;
16     }
17 }

这个是我们的Mock对象，实现了接口，对其中的方法进行指定值的返回。
1 public class MockUserRepository : IUserRepository
2 {
3     public User GetUser(string id)
4     {
5         return new User(){Id = "3577", Name = "Lanvige"};
6     }
7 }

在测试用例中，我们可以用该Mock的对象作为Service的操作对象。这样，我们总能保证测试的最小性和准确性。
   
 1 [TestClass]
 2  public class UserSericeTest
 3 {
 4     public void Get_UserName_By_Id_Test()
 5     {
 6         IUserRepository userRepository = new MockUserRepository();
 7 
 8         UserService userSerivce = new UserService(userRepository);
 9         User user = userSerivce.GetUserNameById("3277");
10 
11         Assert("3277", user.Id);
12         Assert("Lanvige", user.Name);
13     }
14 }

上面的依赖是通对接口来进行解耦的，那对抽像类呢？
答案也是可以的，我们通过父类的overwite来重写方法的返回值。达到Mock的功能。

通过上面的代码，我们即写好了一个测试，又发现了代码中的架构设计问题，那么接下来的就是不停的去Run这个测试，当你有改动代码时就去运行这些Unit test，一旦发现Failed，立即停下手头工作，找到原因，Fix it。
    
原则
   
  • 所有的测试都必须通过
    这一点很重要，不能因为懒惰而产生Failed掉的Case。

     

  • 可重复性
    每一个测试用例在不同时间运行都应得到相同的结果。

     

  • 无依赖性
    测试不应依赖于某一环境、测试数据。在不同的机器上应该都能得到相同的运行结果。

     

  • 最小测
    一个测试用例仅只用来测试一个功能函数，这样的好外是，当这个用例失败时，能很清楚的知道出错位置。

   
实践

   
Q1：如何放置测试数据
   
在我们一个项目中便出现这么一种问题，测试代码要对从TFS中取得的数据进行测试，来验证功能的正确性，在最初的版本中先行者将从TFS中取得的代码放在了C盘，在测试结束后并不进行删除，于是每个开发人员的C盘中就莫名的多了很多的文件，并在不同的机器上运行时出现很多的错误。

解决方案：
每次运行完都记得删除所有的影响。每次运行Test Case，VS都会为我们创建一个测试目录，并随着运行而进行删除，我们可以将数据放在该目录下，从而保证每次运行时的测试数据都是干净的。所有的写操作都是基于该目录进行，不会产生污染。

 

---------

用Chrome在线写该文档时，出现1次Church，两次死掉，换了Firefox后才安心写全，不过掉了很多东西。算作初版。

项目要求Unit Test，是个挑战，在使用过程中总结了一点UT的基本知识和实践中的问题，下一篇中会和大家分享下如何使用Mock Framework和一些经验。

 


Zhiming Jiang

MSN GMD Shanghai

 

 

posted @ 2010-04-28 22:41  Zhiming Jiang  阅读(3881)  评论(10)  编辑  收藏  举报