强烈建议公司进行单元测试，执行每日构建，以提高质量，降低成本。
由于项目的特殊性，我们的项目需要于WebService进行挂接，并且这个部分是项目的核心部分之一，我们在此基础上进行2次单元测试，以保证原始程序（J2EE环境）和调用环境（.Net 2.0）都是可用的。
使用的工具：TestDriven.Net ，NUnit，打算引入NAnt，等项目进入完整功能迭代时将引入Nant。
每天运行2次以上的单元测试用例，以验证代码的修改情况，保证代码的质量。
很多开发人员不愿意进行单元测试，认为浪费时间，其实不然，单元测试可以不考虑界面的逻辑变化，直接使用业务逻辑，从而可以非常快的测试和行业务代码，而界面逻辑本身会随着界面的变化而有所变化，业务逻辑则不同。
开发单元测试所需要花费的时间是不多的，单元测试代码编写完成后，可以不断的循环运行以测试业务代码的增加对系统的影响。
单元测试的前提则是：接口清晰，这对公司的项目的要求提高了，但由此带来的好处是质量会大幅度的上升。因此我强烈建议公司的所有项目都进行单元测试，而不仅仅是日本项目做的以界面为中心的测试，只靠这个测试是无法保证质量的，并且使用界面为中心的测试，会导致界面中包含过多的业务逻辑，使质量下降。最好是先执行单元测试，然后挂接界面，执行界面测试，同样的时间，将会使项目的质量大幅度上升。
对于每日构建，这是国内外软件行家都推崇的方法，我所做的项目每个都必须这样做，每天都要让项目运行一遍，以提早发现软件的Bug。
每日构建的前提是必须在项目的一开始就使用框架，是项目可以运行，所有的代码都在框架的基础上增加，每天下午4点开始编译执行，发现问题当天必须解决才能回家。
当一个软件在交付的时候已经运行几百遍的话，它的质量能不好吗？
因此我强烈的建议公司组织进行单元测试和每日构建。
提高了质量，就意味者成本的下降。为成本而成本，只会使成本看起来下降了，刚开始下降了，而最终却大幅度上升，反而得不到控制，这就是系统论中非常重要的系统基本模型之一，只能控制症状解，不能根本上解决问题，频繁的控制症状解，反而会造成根本解越来越恶化。
文章来源:http://192.168.101.8/blog/040706/archive/2006/07/02/4391.html
