第二章 自動測試
最好的程序員也會犯錯誤。好程序員和差程序員的區別在於：好程序員能通過測試儘可能的發現錯誤。你越快測試錯誤，你就越快發現它們，發現和修正的成本就越低。這解釋了爲什麼只在軟件發佈前才測試的做法爲什麼問題那麼多。大多數錯誤根本就沒有發現過，修正發現的錯誤是那麼的高，以至於你不得不根據優先級來決定只修正那些錯誤，因爲你根本就承受不起全部修正的費用。
相比你正在使用的方法，採用PHPUnit進行測試並不是一個全然不同的東西。它們只是方法不同。兩者之間的不同在於，檢查程序行爲是否符合正確是通過一批可以自動測試的代碼片斷來進行的。這些代碼片斷叫做單元測試。
在這一部分，我們先基於打印的測試代碼進行自動測試。假設我們要測試PHP的內建數組Array。需要測試之一是函數sizeof()，對任何新創建的數組，sizeof()函數應該返回 0。當我們加入一個新數組成員，sizeof()應該返回1。例1顯示了我們想測試什麼。
例1. 測試數組和sizeof()
<?php
$fixture = Array( );
// $fixture
$fixture[] = "element";
// $fixture
?>
最簡單的測試方法是在加入數組成員前後打印sizeof()的運算結果，如果返回0和1，說明Array和sizeof()運行正常。
例2. 採用打印語句測試Array和sizeof()
<?php
$fixture = Array( );
print sizeof($fixture) . "/n";
$fixture[] = "element";
print sizeof($fixture) . "/n";
?>
0
1
現在，我們讓測試程序從需要手工解釋變爲自動運行。在例3中，我們比較了期望值和實際值，如果相等就打印ok。如果我們發現有的結果不是ok，我們就知道有問題了。
例3. 比較Array和sizeof()的期望值和實際值
<?php
$fixture = Array( );
print sizeof($fixture) == 0 ? "ok/n" : "not ok/n";
$fixture[] = "element";
print sizeof($fixture) == 1 ? "ok/n" : "not ok/n";
?>
ok
ok
我們現在引入一個新的要素，如果期望值和實際值不同，我們就拋出一個異常。這樣我們的輸出就更簡單了。如果測試成功，什麼也不做，如果有一個未處理異常，我們知道有問題了。
例4.使用斷言函數來測試Array和sizeof()
<?php
$fixture = Array( );
assertTrue(sizeof($fixture) = = 0);
$fixture[] = "element";
assertTrue(sizeof($fixture) = = 1);
function assertTrue($condition) {
if (!$condition) {
throw new Exception("Assertion failed.");
}
}
?>
現在測試完全自動化了。和我們第一個版本不同，這個版本使得測試完全自動化了。
使用自動測試的目的是儘可能少的犯錯誤。儘管你的代碼還不是完美的，用優良的自動測試，你會發現錯誤會明顯減少。自動測試給了你對代碼公正的信心。有這個信心，你可以在設計上有大膽的飛越（參見本書後“重構”一章），和你的團隊夥伴關係更好（參見本書後“跨團隊測試”一章），改善你和客戶之間的關係，每天安心入睡，因爲你可以證明由於你的努力，系統變得更好了。
--------------------------------------------------------------------------------------------------------------------
原文：
Chapter 2. Automating Tests
Even good programmers make mistakes. The difference between a good programmer and a bad programmer is that the good programmer uses tests to detect his mistakes as soon as possible. The sooner you test for a mistake, the greater your chance of finding it, and the less it will cost to find and fix. This explains why it is so problematic to leave testing until just before releasing software. Most errors do not get caught at all, and the cost of fixing the ones you do catch is so high that you have to perform triage with the errors because you just cannot afford to fix them all.
Testing with PHPUnit is not a totally different activity from what you should already be doing. It is just a different way of doing it. The difference is between testingthat is, checking that your program behaves as expectedand performing a battery of testsrunnable code-fragments that automatically test the correctness of parts (units) of the software. These runnable code-fragments are called unit tests.
In this section, we will go from simple print-based testing code to a fully automated test. Imagine that we have been asked to test PHP's built-in Array. One bit of functionality to test is the function sizeof( ). For a newly created array, we expect the sizeof( ) function to return 0. After we add an element, sizeof( ) should return 1. Example 1 shows what we want to test.
Example 1. Testing Array and sizeof( )
<?php
$fixture = Array( );
// $fixture is expected to be empty.
$fixture[] = "element";
// $fixture is expected to contain one element.
?>
A really simple way to check whether we are getting the results we expect is to print the result of sizeof( ) before and after adding the element (see Example 2). If we get 0 and then 1, Array and sizeof( ) are behaving as expected.
Example 2. Using print to test Array and sizeof( )
<?php
$fixture = Array( );
print sizeof($fixture) . "/n";
$fixture[] = "element";
print sizeof($fixture) . "/n";
?>
0
1
Now, we would like to move from tests that require manual interpretation to tests that can run automatically. In Example 3, we write the comparison of the expected and actual values into the test code and print ok if the values are equal. If we see a not ok message, we know something is wrong.
Example 3. Comparing expected and actual values to test Array and sizeof( )
<?php
$fixture = Array( );
print sizeof($fixture) == 0 ? "ok/n" : "not ok/n";
$fixture[] = "element";
print sizeof($fixture) == 1 ? "ok/n" : "not ok/n";
?>
ok
ok
We now factor out the comparison of expected and actual values into a function that raises an exception when there is a discrepancy (Example 4). Now our test output gets simpler. Nothing gets printed if the test succeeds. If we see an unhandled exception, we know something has gone wrong.
Example 4. Using an assertion function to test Array and sizeof( )
<?php
$fixture = Array( );
assertTrue(sizeof($fixture) = = 0);
$fixture[] = "element";
assertTrue(sizeof($fixture) = = 1);
function assertTrue($condition) {
if (!$condition) {
throw new Exception("Assertion failed.");
}
}
?>
The test is now completely automated. Instead of just testing as we did with our first version, with this version, we have an automated test.
The goal of using automated tests is to make fewer mistakes. While your code will still not be perfect, even with excellent tests, you will likely see a dramatic reduction in defects once you start automating tests. Automated tests give you justified confidence in your code. You can use this confidence to take more daring leaps in design (see "Refactoring," later in this book), get along better with your teammates (see "CrossTeam Tests," later in this book), improve relations with your customers, and go home every night with proof that the system is better now than it was that morning because of your efforts.
