如果我们试着去测试这个方法，很快就会发现一些问题。这些问题是由于定义方法的方式导致的。
我们在测试这个方法时会遇到的第一个困难是，我们调用了一个静态方法——BarManager.getBar()。我们没有办法在单元测试中简单指定如何操作这个方法。还记得我们提过的计划-执行-断言模式吗？但在这里，在通过调用 doSomething() 执行这个方法之前，我们没有一种简单的方式来设置 BarManager。如果 BarManager.getBar() 不是一个静态方法，那么可以向 doSomething() 方法中传入一个 BarManager 实例。在测试集中，传递一个样本值（sample value）是非常容易的，并且我们也可以更好地控制和预测方法的执行过程。
我们还可以看到，在这个示例方法中调用了方法链：aParameter.getValue().isValid() 和 aParameter.getThing().increment()。为了测试它们，我们需要明确地知道aParameter.getValue() 和 aParameter.getThing() 的返回结果类型，然后才可以在测试中构建恰当的模拟值。
如果要做这些，那么我们不得不去了解这些方法返回对象的详细信息。而我们的单元测试就会开始变形，逐渐成为一大堆不能维护的、脆弱的代码。我们正在破坏单元测试中一个基本规则：只测试单独的单元，而不是这个单元的实现细节。
我并不是在说单元测试只能测试单独的类。然而在大多数情况下，把类作为一个单独的单元考虑，可能是一个好主意。但是有些情况下，我们会将两个或者更多的类看做是一个单元。
在这里我为各位读者留下一个练习：对这个方法进行完全重构，使其更容易被测试。但对于新手来说，我们可能会将 aParameter.getValue() 对象作为一个参数传递给这个方法。这样会满足一些规则，提升方法的可测试性。
了解何时使用断言
对于编写应用程序测试来说，JUnit和TestNG都是非常优秀的框架，它们提供了许多不同的方法在测试中对一个值进行断言。例如，检查两个值是相同还是不同，或者值是否为空。
好，既然已经同意断言很酷，那么让我们随时随地使用它们吧！等一下，过度使用断言会使得测试变得脆弱，从而导致无法维护。一旦这样，我们很清楚后面的结果是怎样的——不能被测试和不稳定的代码。
考虑下面的测试示例：
@Test
public void testFoo {
// Arrange
Foo foo = new Foo();
double result = …;
// Act
double value = foo.bar( 100.0 );
// Assert
assertEquals(value, result);
assertNotNull( foo.getBar() );
assertTrue( foo.isValid() );
}
乍一看，这段代码没有什么问题。我们遵循了AAA模式，并断言了一些发生了的事情——那么哪里错了？
首先，我们看到这个测试的名字：testFoo，它并没有真正告诉我们这个测试在做什么事情，并且没有匹配任何一个我们在检查的断言。
然后，如果其中一个断言失败了，我们能够确定测试系统中的哪部分失败了吗？是 foo.bar(100.0) 方法失败了？还是 foo.getBar() 或者 foo.isValid() 方法失败了？如果不通过测试内部调试来试着找出到底发生了什么，我们是无从知道的。
单云测试的目的在于，我们想要一个可信赖的、健壮的测试集。通过快速运行它们，我们可以知道应用程序的状态。而示例中的产生的这种麻烦，已经使得我们的目的落空。如果测试失败，我们不得不运行调试器来找到到底什么地方失败了，那么我们的处境也会变得困难。
通常来说，一种最佳实践是在一个特定的测试中，只有一个最合适的断言。这样我们可以确保测试是明确地，目标是应用程序的单个功能点。
Spy、Mock和Stub，天哪！
有时，Spy应用程序在做什么，或者验证程序使用特定参数调用了特定方法并调用了指定次数，是很有用的。有时，我们想触发数据库层，但又想模拟数据库返回给我们的响应。在Spy、Mock和Stub的帮助下，我们可以实现所有这些功能。
在Java中，我们有很多不同的库，可以用来Spy、Mock和Stub，例如Mockito、EasyMock和JMockit。那么Spy、Mock和Stub之间有什么区别？我们应该在何时使用它们呢？
Spy可以让你很容易检查程序是否使用正确的参数调用了某些方法，并且会记录这些参数以供后面的验证使用。例如，如果你在代码中有一个循环，在每次循环中会触发一个方法，那么Spy可以用来验证该方法被触发的次数是正确的，并且每次触发时都使用了正确的传入参数。对于某些特定类型的存根来说，Spy是至关重要的。
Stub（存根）是一个对象，它可以在客户端触发某种请求时，提供特定的已经存储的响应，例如，针对输入存根已经有通过预编程生成的响应。当你想在代码片段中强行设定某些条件时，存根会很有用，例如，如果数据库调用失败，而你希望在测试中触发数据库异常处理。存根是模拟对象个一个特例。
Mock（模拟）对象提供了存根对象的所有功能，而且它还提供了预编程的期望结果。这就是说模拟对象和真实对象非常接近，它可以根据之前设定的状态来执行不同的行为。例如，我们可以用模拟对象来表示一个安全系统，它根据登录的不同用户，提供不同的访问控制。就我们的测试而言，它会和一个真实的安全系统交互，而我们可以在应用程序中测试很多不同的路径。
有时，我们会使用Test Double（测试替身）一词来表示如上所述的任何类型的对象，我们在测试中会和这些对象进行交互。
通常来说，spy提供了最少的功能，因为它的目的就在于捕捉方法是否被调用。如果被调用，传入的是什么参数。
Stub是下一个级别的测试替身，它通过设置预定义的方法调用返回值的方式，来设定测试系统的执行流程。一个特定的存根对象通常可以在很多测试中使用。
最后，mock object（模拟对象）提供了远比比存根对象更多的行为。就这一点而言，一种最佳实践是针对特定测试开发特定存根对象，否则存根对象就会想真实对象那样开始变得复杂。
不要让你的测试过度DRY
在软件开发过程中，通常让你的应用程序DRY（不要重复自己，Don’t Repeat Yourself）是一种最佳实践。
在测试中，情况并不总是这样。当编写软件时，一种最佳实践是重构那些通用的代码片段，将其放入单独的方法中，那么这些方法就可以在代码中被调用很多次。这样做很有意义，因为我们只编写一次代码，然后也只需要测试一次。另外，如果我们只需要将代码片段编写一次，我们也可以避免由于编写很多次带来的拼写错误。要当心复制粘贴！
2006年，Jay Fields创造了一个新词：DAMP（Descriptive And Meaningful Phrases，描述性和有意义的短语），它用来指代那些设计良好的领域特定语言。如果你想再次回忆，可以参考最初的邮件：DRY code, DAMP DSL。
DAMP背后的原理是这样的，对于一个好的领域特定语言来说，它会使用描述性和有意义的短语来增加语言的可读性，并降低高效使用该语言所需要的学习和培训时间。
通常，在一个测试集中的许多单元测试可能都非常类似，唯一的微小区别就在于如何针对测试准备测试系统。因此，对于软件开发人员来说，将这些重复的代码从单元测试重构到帮助函数中是很自然的。同样将实例变量重构成静态变量也是很自然的，这样它们就可以只针对每一个测试类声明一次——再一次从测试中移除重复代码。
尽管在做出如上重构后，代码会变得更加“整洁”，但这些单元测试作为一个单独的部分会变得更难读懂。如果一个单元测试调用了其它几个方法，并且在使用非局部变量，那么单元测试的流程就变得不直观，并且你也不能够像之前那样容易理解单元测试的基本流程。
至关重要的是，如果我们让我们的单元测试DRY，那么测试的复杂度反而会变得更高，而测试的维护工作也会变得更加困难——这正好和让测试DRY的初衷相违背。对于单元测试来说，让它们更DAMP、而不是DRY，这会增加测试的可读性和可维护性。
关于应该在多大程度上重构你的测试，我们并没有正确或者错误的答案，但我们要努力在让测试过于DRY和过于DAMP之间做一个平衡，这通常肯定会让我们的测试变得更加容易维护。
结论
在这篇文章中，我介绍了五个基本原则，这些原则会帮助我们针对应用程序编写单元测试。如果你有任何想法，欢迎通过下面的评论进行分享，或者你可以在Twitter上找到我：@cocoadavid。
希望你能够希望我们讨论过的这些原则，并且能够看到它们是如何潜移默化地让你热爱编写单元测试。是的，我是说“热爱”，因为我相信编写单元测试是高品质软件的基本要求。
高品质软件意味着满意的用户，而满意的用户意味着幸福的开发人员。
