软件测试中单元测试测什么

　　这是最经常被提到的问题。往往有三个答案：针对代码测试，往往也被称为针对类进行测试。
　
　　针对模块接口进行测试。这种模块往往是没有界面性质的。
　
　　针对业务功能进行测试。类似于模拟需求测试。
　
　　在回答这个问题之前，我们都回顾一下，《测试驱动开发》中，强调的是Story的概念。Story就是一个应用场景。用程序的语言的来翻译的话，就是将需求实例化。
　
　　但是KENT BECK显然没有将这个概念明确化。这样难怪，业务模型，是基于不同层次来说的。如果你只是设计一个类，那么这个类本身也是有需求的。那么这个类的需求和整个软件的需求是不是一致对待呢？
　
　　个人倾向于第三类的测试，一二为补充。
　
　　不过这里重点说一下业务功能的测试难点，那就是模态窗体的测试。这个难点的罪魁祸首是Windows的消息机制决定的。每一个模态窗体都有自己的消息循环（死循环）在处理消息，当从一个模态窗体切换到另一个模态窗体的时候，测试代码就不能继续下去。
　
　　针对这个问题，我的处理方式，就是“解铃还须系铃人”。通过Windows的消息循环就可以穿透这种切换的休克。当然了，处理方式还是比较复杂的。
　
　　单元测试代码不能工作了这往往是单元测试不能继续的借口。应该说，很多人还是热衷于进行单元测试的。可是你在后期询问单元测试的作用的时候，他们就会非常遗憾地告诉你，由于需求变更太频繁，单元测试代码已经不能工作了。
　
　　如果你有相似经验，你会非常赞同这个原因。因为，毕竟单元测试侧重的是软件质量，可是我们往往直接面对的是软件进度。没有人会告诉你面对质量和进度，应该选择什么。但是你知道，你只有选择进度。
　
　　几乎所有的程序员都能明白，前期的质量，会节省后期的进度。但是好像老板不知道。至少，很多程序员都相信这点。
　

[1] [2] 下一页

【责编:Luzi】