PHPUnit's goal in PHPUnit pocket guide

PHPUnit: PHPUnit in the PHPUnit pocket guide. read PHPUnit in the PHPUnit pocket guide. so far, we have only two Tests on Array and built-in function sizeof. When we start to test a large number of array _ * () functions, each of them requires a test. We can start from scratch. However, a better way is to write a test base at a time. "> <LINKhref =

So far, we have only two Tests on Array and the built-in function sizeof. When we start to test a large number of array _ * () functions, each of them requires a test. We can start from scratch. However, a better way is to write a test infrastructure at a time, and then write only the different parts of each test. PHPUnit is such a basic architecture.

Example 5 shows how to use PHPUnit to override two tests in Example 4.

Example 5: Use PHPUnit to test Array and sizeof ().

<? Php
Require_once 'phpunit2/Framework/TestCase. php ';

Class ArrayTest extends PHPUnit2_Framework_TestCase {
Public function testNewArrayIsEmpty (){
// Create an array fixture.
$ Fixture = Array ();
　
// The size of the assertion array fixture is 0.
$ This-> assertEquals (0, sizeof ($ fixture ));
}
Public function testArrayContainsAnElement (){
// Create an array fixture.
$ Fixture = Array ();

// Add a member to the array fixture.
$ Fixture [] = 'element ';
　
// The size of the assertion array fixture is 1.
$ This-> assertEquals (1, sizeof ($ fixture ));
}
}
?>

Example 5 shows the basic steps for writing a test using PHPUnit:

1. the test Class of the Class is ClassTest.

2. ClassTest generally inherits from PHPUnit2 _ Framework_TestCase.

3. the test is a public method with no parameter and the name is test *.

4. in the test method, assertEquals () (see Table 6) is used to determine whether the actual value matches the expected value.

A framework such as PHPUnit needs to solve a series of problems, and some seem to conflict with each other. The test must meet the following conditions:

Easy to Learn

Testing must be easy to learn; otherwise, developers will not learn

Easy to develop

Testing must be easy to develop; otherwise, developers will not develop

Easy to Read

The test code must have no external relationships, so that the test itself will not be lost in disorder.

Easy to execute

Testing should be easy to execute, and the execution results should be expressed in a clear and clear format.

Quick execution

The test should be executed quickly so that thousands of times can be executed every day.

Code isolation

The test sequence cannot affect the result.

Composite

We should be able to run the test in any combination, which is an inevitable result of code isolation.

These constraints have two major conflicts:

Easy to Learn vs easy to develop

Testing usually does not require full flexibility from application to programming. Many test tools provide their own test script language. these languages only have the minimum set of features required for writing tests, because there is no noise to interfere with your test content, and the written test is easy to read and write. However, it is inconvenient to learn a new type of woven mail and a set of tools, which is easy to understand.

Code isolation vs quick execution

If you want the results of one Test to not affect the other, you need to create a full topic for each test at the start stage, and then restore the status before running the test. However, it takes a long time to set the status (for example, connecting to the database and initializing with real data to a known status)

PHPUnit uses PHP as the test language to solve this problem. Sometimes, full-featured PHP is too powerful for short writing and direct testing. However, the programmers we use already have all the experience in using PHP. This is because we need to convince our barely tested staff that it is important to lower the threshold for writing these initial tests.