PHPUnit袖珍指南-第二章 自动测试

第二章 自动测试

最好的程序员也会犯错误。好程序员和差程序员的区别在于：好程序员能通过测试尽可能的发现错误。你越快测试错误，你就越快发现它们，发现和修正的成本就越低。这解释了为什么只在软件发布前才测试的做法为什么问题那么多。大多数错误根本就没有发现过，修正发现的错误是那么的高，以至于你不得不根据优先级来决定只修正那些错误，因为你根本就承受不起全部修正的费用。

相比你正在使用的方法，采用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.