【IT168 技术文章】

　　什么样的测试算是好测试？我们又该怎么知道如何编写好测试？

　　Kent Beck断定，好的测试应该具备下列条件：

　　1. 互相隔离的（不受其他测试的表现形式、是否存在、执行结果的影响）

　　2. 自动化的

　　3. 编写快

　　4. 运行快

　　5. 少有（为开发人员提供自信，而不会由其他测试提供信息，与其他测试不相关）

　　Roy Osherove补充道：好的测试有三个基本属性：可维护、值得信赖、易于理解。

　　Mike Hill的列表要更长：

　　* 它会很短，通常只有十来行代码。

　　* 它不会测试运行程序内部的对象，但是会测试为了测试目的而构建的应用内部的对象。

　　* 它只会调用很小的一部分代码，通常是某个函数的某一分支。

　　* 它是灰盒的形式编写的。也就是说，它运作的方式像是黑盒，但是有时又会利用白盒的长处。（一般来说，这是避免组合问题的重要因素。）

　　* 测试要符合生产代码的编码标准，比如，团队目前对于优秀编码的非常好的看法。

　　* 应用的众多小测试构成了一个“提交关卡”。这就是说，开发人员可以在所有小测试通过的情况下提交代码，否则（强烈建议、甚至不惜手段）阻止他们提交。

　　* 测试应对接受测试的对象有完全的控制权，因此应是自包含的。也就是说，它不会依赖不属于测试代码及其依赖图的任何其他对象。

　　* 它的运行时间非常短。

　　* 它会先于要测试的代码变更之前编写。

　　* 通过一系列slip-and-fake技巧，它会避免使用所有“糟糕”的collaborator。

　　* ……

　　Mike和Ron Jeffries提醒我们：TDD的核心价值是要简化设计、提升开发效率；代码质量的提升和bug数量的减少是因此而带来的重要好处。

　　Jeremy Miller补充了良好单元测试应该具备：

　　* 与顺序无关，并且是隔离的。运行测试的软件可以按照以任何顺序运行。

　　* 意图明确。最好的单元测试应该能够告诉阅读者，一个对象的API是如何准备被调用的。

　　* 易于设置。

　　最后，Ed Burnette写到：要让你的单元测试在任何方面都可以重复；测试边界条件，并且要一直保持测试的通过率是100%。

    查看英文原文

　　What is a good test? How do we know if we're writing good tests?

　　Kent Beck posited, that tests should be:

　　1. Isolated (unaffected by the presence, absence, or results of other tests)

　　2. Automated

　　3. Quick to write

　　4. Quick to run

　　5. Unique (providing confidence not provided by other tests/uncorrelated

　　with other tests)

　　Roy Osherove adds that good tests have three fundamental properties: maintainable, trustworthy and readable.

　　Mike Hill has much longer list:

　　* It is short, typically under a dozen lines of code.

　　* It does not test the object inside the running app, but instead in a purpose-built testing application.

　　* It invokes only a tiny portion of the code, most usually a single branch of a single function.

　　* It is written gray-box, i.e. it reads as if it were black-box, but sometimes takes advantage of white-box knowledge. (Typically a critical factor in avoiding combinatoric issues.)

　　* It is coded to the same standard as shipping code, i.e. the team's best current understanding of coding excellence.

　　* In combination with all other microtests of an app, it serves as a 'gateway-to-commit'. That is, a developer is encouraged to commit anytime all microtests run green, and discouraged (strongly, even nastily) to commit otherwise.

　　* It takes complete control of the object-under-test and is therefore self-contained, i.e. running with no dependencies on anything other than the testing code and its dependency graph.

　　* It runs in an extremely short time.

　　* It is generally written before the code-change it is meant to test.

　　* It avoids most or all usage of 'awkward' collaborators via a variety of slip-and-fake techniques.

　　* ...

　　Mike and Ron Jeffries remind us that the key value of TDD is simplifying design and improving productivity. Improvements in code quality and a reduction in bugs are an important side effect.

　　Jeremy Miller adds that good unit tests should be:

　　* Order Independent and Isolated - it should be possible to run the tests in whatever order the test runner chooses.

　　* Intention Revealing - the best unit tests make it clear to the reader how an objects API is intended to be used.

　　* Easy to Setup

　　Finally Ed Burnette writes: Make your unit tests repeatable in every aspect; Test your boundary conditions and Always keep your tests passing at 100%.