White box testing is a method of testing software. This method test each part(each module and structure) of the application. So it is usually done at unit level of software testing process (each smallest testable part of an application is called unit). This testing methods are also know as clear box testing, glass box testing, transparent box testing, etc….. For doing white box testing tester should have clear idea about the project, and program flow of the project. Rather than idea of project, the tester also need some programming skills.
Test Automation
In simple testing is the process of comparing actual output with predicted output and making report on the basis of comparison. In test automation software is using for execution of testing process.
There are two type of test automation, that are Code driven testing and GUI Testing.
Code driven testing
Create public interface to classes, module and libraries are tested with a variety of inputs.
GUI Testing
Testing framework generate user interface events such as keystrokes, mouse clicks and observe the changes.
As mentioned above white box testing can be considered as unit testing. Usually unit testing can be done by ‘code driven testing’. In order to do code driven testing there some testing frameworks are available. One the important framework is ‘X Unit’.
X Unit
Various code-driven testing framework have come to collectively known as XUnit. These framework allow testing of different elements of s/w suxh as function, class, etc…
Examples of X unit frameworks are
- Junit, Nunit,etc…
- Junit for Java
- Nunit for Dotnet
- PHPUnit for php and there are many frame works available for this.
PHP Unit
PHPUnit give a framework for making a test suite for automate testing of functions and classes. This created by the inspiration of Junit, which was created by Kent Beck and Erich Gamma. The is created as a tool for eXtreme Programming. One of most important rule of XP is test small units of software as often and early as possible.
Extreme Programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements.
Requirements of PHP Unit
– PHP (PHP 5.2 is recommended)
– PHPUnit 4 will require PHP 5.3.
– The DOM, PCRE, Reflection, and SPL extensions are required.
– The CLI-SAPI module of PHP is required to use the Command-Line Test Runner.
– PEAR
In computer science, SAPI (Server Application Programming Interface ) is a generic term used to designate direct module interfaces to web server applications such as the Apache HTTP Server, Microsoft IIS, or iPlanet. For example, PHP has a direct module interface called a SAPI for different web servers. SAPIs are dirrerent for different languages. For example, most common SAPIs for PHP language are PHP CLI and CGI.
PHP CLI is a short for PHP Command Line Interface. As the name implies, this is a way of using PHP in the system command line.
PEAR – PHP Extension and Application Repository
PEAR is a framework and distribution system for reusable PHP components.
The base installation that comes with the PHP distribution contains all the stuff that is needed to run the PEAR installation tools etc…
PHPUnit Installation
PPHUnit can be installed by using PEAR installer.
The PEAR channel (pear.phpunit.de) that is used to distribute PHPUnit needs to be registered with the local PEAR environment. Furthermore, a component that PHPUnit depends upon is hosted on the Symfony Components PEAR channel (pear.symfony-project.com).
pear channel-discover pear.phpunit.de
pear channel-discover components.ez.no
pear channel-discover pear.symfony-project.com
Now the PEAR Installer can be used to install packages from the PHPUnit channel:
After the installation you can find the PHPUnit source files inside your local PEAR directory; the path is usually /usr/lib/php/PHPUnit.
The involve in manula installing given below
1) Download archive from http://pear.phpunit.de/get/, extract it to the directory, directory can be find in the include_path of php.ini file.
2) Prepare the phpunit script:
1) Rename the script named ‘phpunit.php’ to ‘phpunit’.
2) Change the string ‘@php_bin@’ with the path to PHP command-line interpreter(‘/usr/bin/php’ is common).
3) Copy it to a directory that is in your path and make it executable (chmod +x phpunit).
3) Prepare the PHPUnit/Util/PHP.php script:
1) Change the string ‘@php_bin@’ with the path to PHP command-line interpreter(‘/usr/bin/php’ is common).
Writing Test for PHPUnit
Method of project development using PHPUnit contain some main steps following below.
1. Design your class
2. Create a test
3. Implement the class
4. Run the test suite
5. Fix failures or errors and go to #4 again
There are some basic conventions and steps included in writing tests with PHPUnit, that are introduce with examples given below.
1) The class containing tests of a particular class should be named as the example below.
Class to be tested :- ‘String’
Class contain tests of ‘String’ is ‘StringTest’.
2) Class contain tests inherits (most of the time) from PHPUnit_Framework_TestCase.
3) All tests in the class should be public methods. And tests are named test*.
Otherwise, we can use the @test annotation in docblock of method to mark it as a test method.
4) There are many assertion methods such as ‘assertEquals()’ are available in the framework. As name indicate these are used for assert that an actual value matches an expected value. This methods are usually used inside the test methods.
Design a class
[php]<br />
—- stringtest.php —-<br />
<?php class String { //contains the internal data var $data; // constructor function String($data) { $this->data = $data;<br />
}<br />
// creates a deep copy of the string object<br />
function copy() {<br />
}</p>
<p> // adds another string object to this class<br />
function add($string) {<br />
}</p>
<p> // returns the formated string<br />
function toString($format) {<br />
}<br />
}<br />
?><br />
[/php]
Creating test suite
According to steps mentioned above we are going to make test suite. It will check every functions of string class. The test suite is nothing but a PHP class inherited from PHPUnit_TestCase. The test functions are identified by the string ‘test’ precedes by every test functions. By using assert function (from assert*()-family), the actual value and expected values are compared.
[php]<br />
—- testcase.php —-<br />
<?php class StringTest extends PHPUnit_TestCase { // contains the object handle of the string class var $abc; // constructor of the test suite function StringTest($name) { $this->PHPUnit_TestCase($name);<br />
}<br />
// called before the test functions will be executed<br />
// this function is defined in PHPUnit_TestCase and overwritten<br />
// here<br />
function setUp() {<br />
// create a new instance of String with the<br />
// string ‘abc'<br />
$this->abc = new String("abc");<br />
}</p>
<p> // called after the test functions are executed<br />
// this function is defined in PHPUnit_TestCase and overwritten<br />
// here<br />
function tearDown() {<br />
// delete your instance<br />
unset($this->abc);<br />
}</p>
<p> // test the toString function<br />
function testToString() {<br />
$result = $this->abc->toString(‘contains %s’);<br />
$expected = ‘contains abc’;<br />
$this->assertTrue($result == $expected);<br />
}<br />
// test the copy function<br />
function testCopy() {<br />
$abc2 = $this->abc->copy();<br />
$this->assertEquals($abc2, $this->abc);<br />
}</p>
<p> // test the add function<br />
function testAdd() {<br />
$abc2 = new String(‘123’);<br />
$this->abc->add($abc2);<br />
$result = $this->abc->toString("%s");<br />
$expected = "abc123";<br />
$this->assertTrue($result == $expected);<br />
}<br />
}<br />
?></p>
<p>[/php]
The first test run
In this step we are runnig the test. As this example is for studying purpose, we are creating a file given below.
[php]<br />
—- stringtest.php —-</p>
<p> <?php require_once ‘testcase.php’; require_once ‘PHPUnit.php’; $suite = new PHPUnit_TestSuite("StringTest"); $result = PHPUnit::run($suite); echo $result -> toString();<br />
?><br />
[/php]
If you call this script from the commandline, you will get the following output:
: php -f stringtest.php
TestCase stringtest->testtostring() failed: expected true, actual false
TestCase stringtest->testcopy() failed: expected , actual Object
TestCase stringtest->testadd() failed: expected true, actual false
Fix failures or errors
Then it is time for implementation, that is implemeting the class ‘String’ by writing all its functions.
[php]<br />
—- string.php —-</p>
<p><?php class String { //contains the internal data var $data; // constructor function String($data) { $this->data = $data;<br />
}<br />
// creates a deep copy of the string object<br />
function copy() {<br />
$ret = new String($this->data);<br />
return $ret;<br />
}<br />
// adds another string object to this class<br />
function add(String $string) {<br />
$this->data = $this->data.$string->toString("%s");<br />
}<br />
// returns the formated string<br />
function toString($format) {<br />
$ret = sprintf($format, $this->data);<br />
return $ret;<br />
}<br />
}<br />
?><br />
[/php]
If you call this script ‘stringtest.php’ from the commandline again, you will get
the following output:
: php -f stringtest.php
TestCase stringtest->testtostring() passed
TestCase stringtest->testcopy() passed
TestCase stringtest->testadd() passed
The Command-Line Test Runner
The PHPUnit test can be invoke through the command ‘phpunit’. PHPUnit command-line
tool prints on character to indicate progress of test. The characters and descriptions are
listed below.
F:Printed when an assertion fails while running the test method.
E:Printed when an error occurs while running the test method
S:Printed when the test has been skipped.
I:Printed when the test is marked as being incomplete or not yet implemented.
The syntax of executing the PHPUnit is given below.
phpunit [switches] UnitTest [UnitTest.php]
phpunit [switches]
There are many options for switch are available some of them are listed below.
–verbose Output more verbose information.
–wait Waits for a keystroke after each test.
Etc…
Example
phpunit UnitTest
This command runs the tests in the class UnitTest. This class is
expected to be declared in the file named ‘UnitTest.php’.UnitTest must be either
a class that inherits from PHPUnit_Framework_TestCase or a class that provides a
public static suite() method which returns an PHPUnit_Framework_Test object,
for example an instance of the PHPUnit_Framework_TestSuite class.
phpunit UnitTest UnitTest.php
This command runs the tests in the class UnitTest. This class
is expected to be declared in the specified source file named ‘UnitTest.php’.
Fixtures
One of the important part of writing test is writing the code to set
the world up in a known state and return to its original state, after the test.
This known state is called fixture of the test.
PHPUnit supports sharing the setup code. Before a test method is
run, a template method called setUp() is invoked.setUp() is where you create the
objects against which you will test.Once the test method has finished running,
whether it succeeded or failed, another template method called tearDown() is
invoked. tearDown() is where you clean up the objects against which you tested.
setUp() and tearDown() are nicely symmetrical in theory but not in
practice. In practice, you only need to implement tearDown() if you have allocated
external resources like files or sockets in setUp(). If your setUp() just creates
plain PHP objects, you can generally ignore tearDown(). However, if you create
many objects in your setUp(), you might want to unset() the variables pointing to
those objects in your tearDown() so they can be garbage collected. The garbage
collection of test case objects is not predictable.