好的单元测试用例中发现的问题揭露了设计和代码上的缺点。
最近这段时间，对单元测试的介绍急剧地增多。而在上世纪90年代和2000年早期，这一习惯似乎十分无力。通常就是这样，人们采用一项新的技术，回溯当年，各机构们也在从结构化设计方法转向以对象为中心的设计方法，他们将所有的焦点放在至关重要的权利上，同时丢弃看起来不能与新愿景整齐地融合的例行做法。因此单元测试就被忽略了。
但是，很少但是要说我们从过去的10年中学到了什么，那就是我们学到了单元测试是一个非常重要的学科。测试帮助我们更好地来写代码，形成回归基础使得重构和让添加成为特色更简单。有人讨论单元测试的一个十分细微的影响。处在单元层面的可测性和好的设计之间似乎有着某种极为紧密的联系。几乎是公认的说法，难测的代码必有设计问题。当你修复了设计上的问题时，测试就变得简单了。
让我们来看一个例子。
在图1中，我们有一个类，这个类看起来设计不错。有一个公共方法，evaluate()，它是用户与类接触的点。它将其工作传给一系列私有方法。很明显，这样的一个类没有任何错误，RuleEvaluator做了我们想让它做的工作。现在，我们应当怎样为这个类写单元测试用例呢？我们应当能够举例来说明，用多个变量来调用evaluate()方法然后检查结果。但是假如我们想测试getNextToken()方法呢？
......
这个例子也许会惹恼你。你可以认为无需重用getNextToken()或者hasMoreTokens()方法中的代码，将他们拉进其类中是无意义的，因为这无意义地增加了类的数量。但是作这个动作的确让代码更有模块化的概念。我们可以在将来的某个点重用RuleTokenizer方法。至少，现在很清晰，我们应当在标记功能代码的哪些地方做改变。我们的代码相关性更加少，改变其中一个而不影响另一个更容易。
如果这是可测性不高是设计差的一个信号的唯一例子的话，这只会被认为是侥幸，但实际不是这样。通常来说，单元测试的痛是有地方出错了的表示。有时这种痛很明显。举例来说，如果你必须创建很多对象才能得到你想测的那一个对象，这常常是过度耦合的一个表现。其他的情况更微妙。我们来仔细观察一些例子。
......
版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像，否则将追究法律责任。
