测试 代码的一些体会！说实话，前半部分能看懂，因为深有感触

测试的一些体会

在写完一个类之后，做一下测试是在所难免的。这个文想讨论一下以往个人采用的一些做测试的方法，并从他们的优劣之处加以比较。只是需要注意的是，这里的测试和调试的含义并不相同。测试主要针对于整个类，打进去输入看看输出对不对，在这篇文里它仅仅是一个check的过程。至于调试，则发生在测试失败时，此时就需要跟踪到类的内部逻辑中去，看一条条语句是如何执行的。二者的概念和所应用的工具都是不同的。当然，这两者也没有什么本质的区别，只是粒度不同而已。事实上对某一个类的测试也可以看做是对整个程序的调试。
最原始的测试方式当然是在原工程里直接乱搞，想想看当年在写数据结构实验的时候就是这样的:-) 可怜昱姐接收到的代码质量都不高:-P 直接在Main()函数中编写一些测试数据和测试步骤，Ctrl+F5，就出来结果了。这样的方法相当的简便易行，只是存在各种各样的坏处，比如Main()函数的工作代码和测试代码夹杂在一起，时常要把原先大段的工作代码注释掉，换上测试代码，然后再注释回去...工作流程相当的搞笑。总之这样的方法在大二后就不敢再用了，除了显而易见的弊端之外，还有一个问题是Main()函数找不到了 T_T 不论是MFC还是WPF，[mM]ain()函数都是封装起来的~ 这样如果继续沿用这种方法的话，测试代码就要分散在整个程序中。一个很可能的结果就是最终Release版里面蓦然一个对话框"叮"的蹦出来显示一串不知所云的数字：因为忘了删测试代码了... 用_DEBUG又好麻烦...就改革啦~
后来先进一点了，知道了C#的Windows Application也是可以作为Console Application编译的，窗口部分的效果不变，只是运行的时候会蹦出来一个黑黑的命令行窗口，Console类也可以使用了。这下就方便了许多，测试结果和状态信息可以在Console里面显示，最终发布程序的时候只要把编译类型再改回Windows Application就好，不会有什么负面影响。发现这种方法之后，测试方便了不少。一个类写好以后，装载到整体环境中去，在这个类工作完毕的地方加上一定的输出语句，运行。执行一定的测试步骤(比如单击某某菜单项等）时，就可以看到类的工作结果输出啦。
不过这样地方法毕竟还是有缺陷，杂七杂八的调试代码和真正干活的代码在一起总不是很爽。所以就学会了新建一个Console工程叫做Test，这个工程里专门进行各种各样的测试工作，调这个类，输一个结果，调那个类，再输一个结果~~实际发布的时候不编译它就好了。总之就是实现了测试代码的隐蔽化和集中化。但这样还是有不足的地方，一般情况下一个solution总是有数个namespace。而每个namespace下总是有private的类，Test工程根本就无权调用它... 所以还是要在程序代码中手动添加#if DEBUG public #endif。晕，好麻烦... 而且数个namespace造成的最直接的恶果就是Test工程要加上一坨using和Reference，大一点的工程，再调几个库，手都打废的了。
如今发现了VSTS还有Unit Test这个东西，似乎挺不错的。它最大的特点就是自动化。右击一个类，点Create Unit Test...，电脑硬盘一阵狂响，测试代码的主体框架就写好啦。自动针对这个类的每一个property, method, constructor都生成了相应的测试函数。把需要的函数稍微改改，调整一下参数，不需要的函数直接Ctrl+M, O，删掉。不用费神加输出语句，不用加public，不用加reference，不用加using，不用想最终Release版会不会出漏子... 唉，这样的生活还是很爽的~ 而且运行测试工程的时候看起来巨牛文明用语，一个进度条滚啊滚，一个个测试逐个显示Pass, Fail, Inconclusive，那叫一个专业，新一代的装文明用语利器啊~~
在我军实现机械化，现代化，最终实现信息化的同时，我们的测试工作也完成了集中化，隐蔽化和自动化的改装。当然我不是专业的软件测试人员，什么黑盒测试白盒测试一概不懂，只是说说在编程的时候怎么看看自己费心写出来的小程序对不对。恩啊~~继续写我的小程序，过甜蜜的小日子去咯~还有FangHua大业，ZhengYangLou还不晓得什么时候出来哩~

P.S.小自恋一下，这些感触没有经历过七八万行代码的经验和不断的思考，一般学生，比如物理系啊考古系啊的还真没有~

Tag标签: C#,VSTS,Testing

一旦友谊破裂，名誉受玷，忠诚变为罪恶和可耻的隐痛，以前的一切仅留下一个不停地出血的创伤，永远不可能愈合。——温塞特