首先,给出MSDN相关地址:http://msdn.microsoft.com/en-us/library/Microsoft.VisualStudio.TestTools.UnitTesting.aspx (类库)
Verifying Code by Using Unit Tests (介绍)
我的IdleTest源码地址:http://idletest.codeplex.com/
VS2012单元测试的主要类:Assert、StringAssert、CollectionAssert,具体可参照上述链接的MSDN介绍。
单元测试一直都想接触,但是碍于没有那样的工作环境,故只能由自己在业余时间去做这个事,整个过程下来,最大的感触是我写代码的质量原来可以这么好,在此之前,通常我编写的代码有很大一部分在程序运行前都是有bug的,但是通过单元测试,基本上在程序运行之前(调试阶段)就扼杀了这些bug的大多数,单元测试代码有问题除外,这也是我坚持单元测试的最大动力,其次就是单元测试可以促使我在编码中努力去遵循SOLID,提别是单一职责原则。
我个人在学习单元测试中基本都写成了博客,便于记录,以下为目录。
目录:
1.《在Visual Studio 2012使用单元测试》、
2.《VS2012 单元测试之泛型类(Generics Unit Test)》、
3.《VS2012 Unit Test —— 我对接口进行单元测试使用的技巧》
4.《VS2012 Unit Test(Void, Action, Func) —— 对无返回值、使用Action或Func作为参数、多重载的方法进行单元测试》
5.《VS2012 Unit Test——Microsoft Fakes入门》
6.《VS2012 Unit Test —— 我对IdleTest库动的大手术以及对Xml相关操作进行测试的方式》
插曲:前段时间与某个公司的开发经理(反正是管理开发的)聊过,问我最近在搞什么技术,答曰小酌单元测试,其反问”要改当测试人员了啊“。由此可见还是很多做开发的误以为单元测试应由测试人员来做,单元测试应该是100%由开发人员完成,甚至我们码农还要编写集成测试代码。
单元测试只是TDD的一部分,其他的例如还有集成测试等。而TDD不但是编码的事,还是测试的事,更是设计的事,即为整个项目团队的事,所以绝对不是说用就用的,我这也算是发发牢骚罢了,发完还是要回头去干改bug的活。
以下摘自《C#测试驱动开发》。
TDD优点(简言之就是使设计更佳,缺陷更少):
1.一开始就保证代码的质量;
2.使开发人员更遵循SOLID原则;
3.确保代码与业务需求之间的高度一致性;
4.TDD鼓励创建更简单、针对性更强的库和API;
5.鼓励与业务用户多沟通;
6.有助于从系统中清除那些没有用到的代码;
7.提供了内置回归测试;
9.可以得到开放的、可扩展的、灵活的体系结构。
单元测试框架:NUnit、MSTest(上述文中所用的)、MbUnit、xUnit。
模拟框架:Fakes(MSTest的模拟框架)、Moq、Rhino Mocks、Type Mock
依赖注入框架:Structure Map、Unity、Windsor、Autofac
能力有限,错漏难免,欢迎批评指正!!
参考资料:MSDN、C#测试驱动开发(Professional Test Driven Development with C#)