[Bad JUnit] 不要用JUnit测试void方法

今 天在某论坛上看到了这样的一个帖子“用Junit测试void方法”，实际上JUnit在CookBook中已经很详细的说明了JUnit不要介入对无返 回值的方法测试，并且在某些测试的CheckStyle中这样的测试方法会被标记为一个ERROR。在编程语言的方法上存在着两种形态，早先在VB中就很 清楚的描述一种为Function，另外一种为Sub，Function和Sub最大的名词区分为“方法”和“过程”。 回过头来看看C++的一些代码，凡是涉及到重要业务的，例如AutoGenDb出来的代码基本上都会返回一个int值，用来标示方法处理后的成功和失败。那么有人说了，你这么说过程就不需要测试了，我们的开发偏偏不喜欢返回值，那么就不用测试了？ 实际上在测试驱动中有个著名的连带动作“重构”，例如我们有个这样的方法： public class User{   String user = null;   int age     = null;   int six       = null; ... ... } 重构前： public void insert(User user){   ... ...;   db.insert("Table_Name",user.user,user.age,user.six); } 重构后： public boolean insert(User user){   ... ...;   try{     db.insert("Table_Name",user.user,user.age,user.six);   }catch(DbException dbe){     System.out.pringln("DbError:" + dbe.getMessage());     return false;   }   return true; } 这样用JUnit写测试代码： public void testInsertOk{   assertTrue(insert("fastpoint",30,1));//正确测试 } public void testInsertFail{   assertTrue(insert("FASTPOINT",99,2));//错误测试 } 重构后的代码可以增加对异常的测试，实际上我们的重构也“过度”了，其实代码只要重构到这种程度就可以了，即不要改变原来的代码接口规则： public void insert(User user){   ... ...;   try{     db.insert("Table_Name",user.user,user.age,user.six);   }catch(DbException dbe){     System.out.pringln("DbError:" + dbe.getMessage());   } } JUnit也提供了一些特殊方式进行测试，例如： public void testInsertOk{   assertTrue(insert("fastpoint",30,1));//正确测试 } public void testInsertException{   try{     insert("!@#$%^&*",100000,3746528);   }catch(DbException dbe){     // successful test   } } 使用JUnit不要过于机械，一个很活动的框架不是只让你来判断 1=1 或者 2=2 的，并且使用JUnit做类测试千万不要站在测试人员的角度去思考问题。如果断言类提供的方法不够你测试，那么你就要进行继承、扩展或者覆盖动作。 如果原贴主看到了这个帖子，我有些问题想问你： 你写那样的测试是站在什么立场？ 你写的测试代码以后如何适应被测试代码的变更？ 你写的测试代码只有你一个人用吗？