PHPUnit袖珍指南 第九章 测试优先编程
第九章 测试优先编程
单元测试是几种软件开发实践和过程至关重要的部份，譬如测试优先编程，极限编程[3]，测试驱动开发[4]。 单元测试也允许在结构上不支持的编程语言中支持契约式设计[5]。
[3] http://en.wikipedia.org/wiki/Extreme_Programming
[4] http://en.wikipedia.org/wiki/Test-driven_development
[5] http://en.wikipedia.org/wiki/Design_by_Contract
您可以完成代码后使用PHPUnit。但是，代码有错误，越快找到它们，测试就越有价值。因此，与其在代码错误“完成”后几个月才写测试，我们可以在缺陷引入后几天，几小时甚至几分钟内就写好它们。对了，为什么这样就够了？为什么不在一个缺陷引入前就写好测试呢？
测试优先编程，是极限编程和测试驱动开发的一部分，基于这种想法并发挥到了极限。以今天的计算机能力，我们可以每天进行数千次的测试，每个测试运行数千遍。我们能使用所有这些测试的反馈来编程，就向小步跑，除了以前有的测试之外，每步都有自动化的测试作保证。测试就是岩钉一样，保证不管发生了，一旦取得了进展，就会固定已有的进展。
当你第一次写测试时，它可能无法运行，因为你在调用还未实现的对象和方法。这也许起初让人感到奇怪，但你会很快习惯它。测试优先编程被认为是一种有效的的实践，符合面向对象的编程技术原则：面向接口而不是面向实现。当你写测试时，你就在考虑正在测试的对象的接口。从外面看，对象应该什么样？当你真正地让测试可以运行，你就是在考虑纯实现。接口会被失败的测试固定下来。
接下来简单介绍一些必要的测试优先编程内容。你可以在其他其它的书中找到更多的议题，譬如《举例说明测试驱动开发－Kent Beck》（Addison Wesley）或《测试驱动开发：Dave Astels的实践指南》（Prentice Hall）。
--------------------------------------------------------------------------------------------------------------------
原文：
Chapter 9. Test-First Programming
Unit tests are a vital part of several software development practices and processes, such as test-first programming, Extreme Programming,[3] and test-driven development.[4] They also allow for design-by-contract[5] in programming languages that do not support this methodology with language constructs.
[3] http://en.wikipedia.org/wiki/Extreme_Programming
[4] http://en.wikipedia.org/wiki/Test-driven_development
[5] http://en.wikipedia.org/wiki/Design_by_Contract
You can use PHPUnit to write tests once you are done programming. However, the sooner a test is written after an error has been introduced, the more valuable the test is. So, instead of writing tests months after the code is "complete," we can write tests days, hours, or minutes after the possible introduction of a defect. Why stop there? Why not write the tests a little before the possible introduction of a defect?
Test-first programming, which is part of Extreme Programming and test-driven development, builds upon this idea and takes it to the extreme. With today's computational power, we have the opportunity to run thousands of tests, thousands of times per day. We can use the feedback from all of these tests to program in small steps, each of which carries with it the assurance of a new automated test, in addition to all the tests that have come before. The tests are like pitons, assuring you that no matter what happens, once you have made progress, you can only fall so far.
When you first write the test, it cannot possibly run because you are calling on objects and methods that have not been programmed yet. This might feel strange at first, but, after a while, you will get used to it. Think of test-first programming as a pragmatic approach to following the object-oriented programming principle of programming to an interface instead of programming to an implementation: while you are writing the test, you are thinking about the interface of the object you are testingwhat does this object look like from the outside? When you go to make the test really work, you are thinking about pure implementation. The interface is fixed by the failing test.
What follows is a necessarily abbreviated introduction to test-first programming. You can explore the topic further in other books, such as Test-Driven Development: By Example by Kent Beck (Addison Wesley) or Test-Driven Development: A Practical Guide by Dave Astels (Prentice Hall).