单元测试的一些问题

在部门推广单元测试，碰到了一些问题：

1、测试框架应提供的功能
  首先是一个公共测试基类，定义了数据源，是用JPA的，直接用注解定义了数据源。A项目报表比较多，经常需要准备很多测试数据，A项目的负责人想把该功能集成到测试基类中，我认为该功能是A项目独有的，不需要集成到测试基类，可封装到A项目的测试基类。

2、测试粒度
  测试粒度我认为是类的一个方法，在我们组里对应的应该是Service层的方法，DAO层是JPA的，用注解写的，全部是接口。B项目负责人认为测试粒度应该是一个业务，该业务可能做了很多事情。我认为这种业务应该把事情再细分，逐一进行单元测试，再进行业务的集成测试，至少关键的方法要写对应的单元测试。

3、测试时机
  真能做到TDD吗，即先写单元测试再写实现代码。现在基本都是写了实现代码，再写测试代码，这可能也受进度影响。而且单元测试代码基本如2所说的，就对主要业务写一个测试。感觉有点敷衍了事。

4、单元测试要关注什么
  由于我们刚单元测试刚起步，我推荐了Junit, Emma, EasyMock等工具，并指出要关注逻辑覆盖，但部分人员认为，我们初步先注重编写单元测试，可以不管单元测试的质量，只关注输入输出，所以先使用Junit，逻辑覆盖测试也不要求那么高，在Excel里面定义了输出输出并说明单元测试要做的事情，实际的测试代码能够完成Excel里定义的输入输出就行了。

 

5、有关单元测试的覆盖率

   要求覆盖率要达到80%，但这个覆盖率怎样定义呢？关键方法的覆盖率，关键业务的覆盖率，还是类的覆盖率，还是测试代码达到业务代码的80%？这个也是公说公有理，婆说婆有理的。

大家在实际中有遇到这些情况吗？有什么高见拿出来跟兄弟分享一下。

覆盖率有啥好公说公有理，婆说婆有理
语句覆盖,分支覆盖,条件覆盖,路径覆盖选一种,连术语都不确定,自然就变成公说公有理，婆说婆有理
有句话叫,你不知道你不知道的事

Y说得对，Y的术语说得“好”，Y是不是在赶上战场啊。。。

Y不是要上战场的话，就顺便指点一下其它几条，用专业一点的术语分享一下Y的心得

Y要是上战场的话，Y来凑什么热闹