项目中经常遇到这样的问题，写好的模块，由于需求的变更，数据库字段进行了修改，逻辑也有些变更，于是乎，在一大堆代码修改后，进行运行界面开始测试。无奈一次不可能写对所有的逻辑，或者连字符都拼错。尤其是做B/S系统的时候，调试好一个功能，往往花费你大量的时间。而且，有更改的话，还要重来一遍，如果遇上些关联关系，调试测试就更加复杂了。并且，在项目做了N个模块后，又修改了一个功能，说实话，天知道其他逻辑是否产生BUG了没，呵呵。
所以，引进单元测试还是很有必要的，合理使用，还是很能够改进代码质量。看似CODE的时间延长了，实际上却大大的缩短了DEBUG时间，并且大大减少了修改功能影响其他方法的边际相应。
如果做是比较好的实践呢？
一般大家都使用Nunit,这个不难，随便园子里面、网上都能搜到很多入门文章，我也不在复述。只谈谈注意事项。
1.测试只需做到逻辑操作的测试、数据crud的测试就行了。前端ui数据的收集显示不是Nunit做的。我们的任务是确保传送给ui的数据是正确的就行了。
如图，在标准的demo中，我只进行了bll和dal层的测试
2. 测试数据库最好和平时使用的数据库分开，因为平时的测试数据并不能很好的解决自动化测试的问题,如上图，用app.config单独进行了库的配置（DEMO用的是同一个库）
3.测试数据根据情况进行构造和清理
有时候数据需要清理，但有时候不需要，因为做分类测试的话，有些数据保留比较方便，因此，尽量使用[Test,Category("xx")] 进行分类
4.跟据模块来测试提高效率和测试效果
通过分类测试，更容易的看出某个模块的问题，有时候，单独测试一个方法的数据并不能说明什么问题
5.结合TestDriven.net让你事半功倍，结合这类vs的add-in工具，测试变得更加方便了，nunit成了摆设，基本上打开他是为了看到绿色的进度条来爽一把。