第九章 測試優先編程
單元測試是幾種軟件開發實踐和過程至關重要的部份，譬如測試優先編程，極限編程[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).