So far, we have only two tests for Array and the built-in function sizeof(). When we start testing a large number of array_*() functions, we need a test for each one. We can write each one from scratch. However, a better approach is to write the test infrastructure once and then only write the different parts of each test. PHPUnit is such an infrastructure.
Example 5 shows how to rewrite the two tests in Example 4 using PHPUnit.
Example 5. Test Array and sizeof() with PHPUnit.
<?php
require_once 'PHPUnit2/Framework/TestCase.php';
class ArrayTest extends PHPUnit2_Framework_TestCase {
public function testNewArrayIsEmpty( ) {
//Create array fixture.
$fixture = Array( );
// Assert that the size of the array fixture is 0.
$this->assertEquals(0, sizeof($fixture));
}
public function testArrayContainsAnElement( ) {
//Create array fixture.
$fixture = Array( );
// Add a member to the array fixture.
$fixture[] = 'Element';
//Assert that the size of the array fixture is 1.
$this->assertEquals(1, sizeof($fixture));
}
}
?>
Example 5 tells us the basic steps to use PHPUnit to write tests are:
1. The test class for class Class is ClassTest.
2. ClassTest generally inherits PHPUnit2_ Framework_TestCase.
3． Test is a public method with no parameters and its name is test*.
4. In the test method, assertion functions such as assertEquals() (see Table 6) are used to assert whether the actual value matches the expected value.
A framework like PHPUnit needs to solve a number of problems, some of which seem to conflict with each other. Tests must also meet the following conditions:
Easy to learn
Tests must be easy to learn, otherwise, developers will not learn
Easy to develop
Tests must be easy to develop, otherwise, developers will not develop
Easy to read
Test code must have no external relationships, so that the test itself will not Get lost in the clutter.
Easy to execute
Tests should be easy to execute and the results of execution should be expressed in a clear and unambiguous format.
Fast Execution
Tests should be executed quickly so that they can be executed thousands of times per day.
Code isolation
tests cannot affect each other, and changes in test order should not affect the results.
Composable
We should be able to run tests in any combination, which is a corollary to code isolation.
There are two main conflicts between these constraints:
Ease of Learning vs Ease of Development
Testing generally does not require the full flexibility of programming. Many testing tools provide their own test scripting languages. These languages only have the minimum set of features needed to write tests. Because there is no noise to interfere with your test content, the written tests are easy to read and write. But learning a new knitting mailer and set of tools is still inconvenient and easily confusing.
Code Isolation vs. Fast Execution
If you want the results of one test to not affect another, you need to create a full topic for the test at the beginning of each test, and then restore the state before running. However, setting up the state takes a long time (for example, connecting to the database and initializing to a known state with real data).
PHPUnit's solution to this problem is to use PHP as the testing language. Sometimes, full-featured PHP is too powerful for writing short, straightforward tests, but the programmers we use already have full experience with PHP. Because we need to convince reluctant testers, lowering the barrier to writing these initial tests is extremely important.