很多开发团队的开发流程中，肯定有一项是要求开发人员要做单元测试。但是，实际的执行情况却差强人意。有的可能是把整个系统启动起来，然后把调试器连上去，设置断点，在调试环境中修改变量的值以模拟不同的情况或者边界条件。有的可能是写了一些XUnit的测试案例，但是写完以后可能执行一次，以后再也不会执行了。这些都不能完全发挥单元测试的作用。

　　究其原因，我觉得是其中的一个原因是开发团队中没有良好的单元测试环境，也许开发人员想写点XUnit的测试案例，但是由于没有良好的环境支持，也作罢了。所以想要做好单元测试，先要提供良好的环境支持。

　　下面我谈谈我认为良好的单元测试环境应该包含哪些方面。

　　1、测试案例要有明确的存放地方

　　在SCM（Source Code Management）中，要有明确的目录存放单元测试案例的目录，一般应该和源代码放在一起。比如在java中，生产代码放在src目录中，测试代码放在test目录中，它们都放在同一个目录里面。在.Net中也是类似，生产代码的工程和单元测试代码的工程都在同级目录里面。这样才不至于开发人员想要测试案例，但是写了也不知道放哪里的情况。

　　2、开发环境中要有测试支持库（Test Support Library）

　　把单元测试中能被重用的工具方法，公共测试准备的代码放在一起，让开发人员能专注在写代码和测试案例上面，而不是把时间花在环境设置上面。不要把测试代码看成比生产代码低一等的公民，应当象对待生产代码一样去设计测试代码。

　　3、测试案例要能持续地被执行

　　如果单元测试案例只被执行一次，那么单元测试的不能完全发挥其避免regression issue的作用。开发团队应建立持续集成的环境，让每次代码提交的时候都执行一次编译并且执行单元测试案例。这样，开发人员花时间精力写出来的测试案例才能大化地发挥其作用，同时也能保证测试代码随着生产代码持续更新。

　　4、测试案例执行结果要公开化，让所有团队的人随时能访问测试结果

　　曾经做的一个项目，我们从开始非常重视单元测试，写了和生产代码差不多的测试代码，但是测试结果没有放在一个公共的地方被管理起来，只有在执行结束后在临时目录能看看。所以，久而久之，我们也不知道测试的覆盖率怎么样，也不知道自己写了那么多测试有什么实际的效果（但是后来的QA的测试结果显示这些具有良好单元测试的代码几乎没有发现Bug，除非是需求变更或者与系统其他部分集成的问题）。现在，我们把测试结果放到了Sonar（参见.Net项目与Sonar的集成）里面，很清楚地知道一共有多少测试案例，新增了多少案例，测试覆盖率几何，哪些代码没有被覆盖到，哪些测试执行时间很长，等等。这样，开发人员新写了测试案例，在Sonar里面能看到其对系统的贡献，能看到自己的代码在使得系统朝着越来越好方向发展，这样能增强开发人员的信心。

　　5、系统的设计应考虑可测试性

　　这一点本不应该是本文的内容，但是我觉得很多时候开发人员不写测试案例实在因为代码没法测试，比如一个类20000行，一个方法2000行，这样的代码要让它跑起来，要依赖一大堆东西，很可能整个系统都得跑起来。这也造成了开发人员宁可把系统跑起来，用调试器连上去做测试，也不愿写单元测试案例。所以，在设计系统的时候要考虑系统的可测试性。关于这个话题，以后再写了。

　　总之，开发环境要尽量考虑到开发人员的体验，只有很容易写测试案例，开发人员才愿意并能写更多的测试案例。当然，作为一名有理想有抱负的开发人员，应该主动想办法来改善目前的开发环境。