优美的测试代码 - 行为驱动开发(BDD)

可理解的代码非常重要，测试代码也是如此。在我看来，优秀的测试代码，必须做到一个重要的事情就是保持测试逻辑的清晰。一个完整的测试案例通常包括三个部分：
1. SetUp
2. Exercise
3. Verifiy
4. TearDown
一 个测试案例如果能清晰的区分这三个部分，其实已经成功了一半。但是，如果仅仅只是做到这一步，离我们的“可理解的”测试代码还有些距离。在我看来，要做到 测试代码的可理解， 首先要做到的是 使 用简洁清晰的方式表达每个测试案例的测试过程。我们都不希望在一个测试案例中看到一个long long method，因为我们需要去理解，你调用了那么多方法，做了那么多处理，到底是在干啥？当然，我们也不希望看到一个极端情况：一个测试案例中就看到一个 函数调用。这样做确实做到了测试案例表面上的简洁，但是，却失去了表现内部细节的机会。我们需要表述的是测试过程和方法，比如，进行了什么样的操作，输入 了什么样的数据，然后得出了什么样的结果，和预期结果对比怎么样等。如果把这些都封装到一个方法，别人只能理解你可能会做什么，但很难去理解你将如何去 做。 其次， 在测试案例fail的时候，能够清晰准确的定位问题。极限情况下，一个测试案例里应该只能有一个断言，或者说一个检查点。测试粒度的缩小能够加 快问题的定位。通常，当一个测试案例fail的时候，我们还需要定位到底是测试代码的问题还是被测代码的问题。这是一个烦人的过程，定位问题的人不一定就 是写这段测试代码的人，就算是写这段测试代码的人，也需要时间去理解测试案例干了什么。这时，测试过程及方法的清晰表述就变得尤为重要。
有的人会 想到通过文档来表述测试过程和方法，在我看来，这不是一个好办法。敏捷开发中的一个思想：“ 一个过时的文档比没有文档更加糟糕”。为什么需要文档才能表述清楚你的测试过程？ 只能说明你的测试代码足够糟糕，无法让人理解。一个糟糕的代码就算当初写下了足够详细的说明文档，随着时间的交替，人员的变更，代码的修改维护，复杂的文 档和代码会变得越来越不同步。导致的结果将会是代码越来越糟糕复杂，文档越来越过时。 最好的文档，其实是代码。
我们先来看一下一个老外写的完整的测试案例代码：