History of TestingSuites

Comparing versions
Version 8Current version
If you don't know about Object Orientation (OO) or 'Black Box' design, take a look at the ObjectOrientation page. Its probably also a good time to read ModelViewController to understand how all this fits together.

Under the kernel/test/ directory, you will find an attempt at our first testing suite. This is supposed to be a quick explanation on how it works.

The testing suite is based on the principles of Object Orientation or 'black box' design. The testing suite only cares about what could possibly go into a class, what if something not meant to go into the class is handled and will the output be the way you like it.

As OO uses a lot of inheritence, by changing something small in a base class, all child classes could be affected and break. Testing suites help prevent this. Also, if developers start putting data into the class, that was never meant for it, testing suites ensure that the class handles them gracefully, rather than die a horrible death.

Lastly, a testing suite also checks that the output is what you expected.

I had a look at PEAR::PHPUnit, which appears to be a little complicated for our needs. Both PHPUnit and the testing script work in very similar ways, but the testing script is much more simple to setup and use.

The testing script we use was written by Vincent Oostindië, and can be found at http://www.phppatterns.com/index.php/article/articleview/33/1/2/. Its very simple in design and perfect for our need in TikiPro. You can find a copy of the script as kernel/test/index.php.

So, using our class from ObjectOrientation, I'll show you how to write a test class for it.

In a directory, place the index.php script. Now, create a new file using the prefix Test - in this case TestMyClass.php.

Some points to remember for test classes:
  1. The test scripts need to include the script they will be testing (obviously).
  2. Create one test class per test script, the class name being the same as the file name.
  3. All test classes must extend a class Test
  4. All methods within the test class beginning with the letters "test" will be executed by PHPUnit

So, for our class, this is what the test class would look like:
{CODE(colors=>php)}<?php
// get the class you're going to test
require_once('MyClass.php');
// always extend the Test class, which is already included from index.php
// always prefix the class name with 'Test'
class TestMyClass extends Test {
// this variable will hold our test class
var $test;
// initialise class and confirmed its setup correctly.
function TestMyClass() {
$this->test = new MyClass();
Assert::equalsTrue(isset($this->test), 'Error during initialisation');
}
// check if the initial value is 'not-set'
function testGetInitialValue() {
Assert::equalsTrue($this->test->getText() == "not-set", 'Default value is not correct');
}
// set value and test that it sets
function testSetValue() {
$this->test->setText("some test");
Assert::equalsTrue($this->test->getText() == "some text", 'Value is not set');
}
}
?>{CODE}
As you can see, its really not too hard. By browsing to the index.php file, each of the Test* files and classes will be initialised and their results presented on the screen.

The next steps to this test class could be:
  • what if you tried to set the text to NULL?
  • what if you tried to set the text to ""?
 
If you don't know about Object Orientation (OO) or 'Black Box' design, take a look at the ObjectOrientation page. Its probably also a good time to read Model View Controller - MVC to understand how all this fits together.

Under the kernel/test/ directory, you will find an attempt at our first testing suite. This is supposed to be a quick explanation on how it works.

Before you go any furhter you can run the testsuite to get a feel of its output.

The testing suite is based on the principles of Object Orientation or 'black box' design. The testing suite only cares about what could possibly go into a class, what if something not meant to go into the class is handled and will the output be the way you like it.

There is also a new testing package: bitUnit. The bitUnitPackage is an integration of simpletest at sourceforge. It was chosen since it was the only package that supports the MVC pattern, which made it possible to integrate with smarty templates.

As OO uses a lot of inheritence, by changing something small in a base class, all child classes could be affected and break. Testing suites help prevent this. Also, if developers start putting data into the class, that was never meant for it, testing suites ensure that the class handles them gracefully, rather than die a horrible death.

Lastly, a testing suite also checks that the output is what you expected.

I had a look at PEAR::PHPUnit, which appears to be a little complicated for our needs. Both PHPUnit and the testing script work in very similar ways, but the testing script is much more simple to setup and use.

The testing script we use was written by Vincent Oostindië, and can be found at http://www.phppatterns.com/index.php/article/articleview/33/1/2/. Its very simple in design and perfect for our need in bitweaver. You can find a copy of the script as kernel/test/index.php.

So, using our class from ObjectOrientation, I'll show you how to write a test class for it.

In a directory, place the index.php script. Now, create a new file using the prefix Test - in this case TestMyClass.php.

Some points to remember for test classes:
  1. The test scripts need to include the script they will be testing (obviously).
  2. Create one test class per test script, the class name being the same as the file name.
  3. All test classes must extend a class Test
  4. All methods within the test class beginning with the letters "test" will be executed by PHPUnit

So, for our class, this is what the test class would look like:

<?php
// get the class you're going to test
require_once('MyClass.php');
// always extend the Test class, which is already included from index.php
// always prefix the class name with 'Test'
class TestMyClass extends Test {
  
// this variable will hold our test class
  
var $test;
  
// initialise class and confirmed its setup correctly.
  
function TestMyClass() {
    
$this->test = new MyClass();
    
Assert::equalsTrue(isset($this->test), 'Error during initialisation');
  }
  
// check if the initial value is 'not-set'
  
function testGetInitialValue() {
    
Assert::equalsTrue($this->test->getText() == "not-set"'Default value is not correct');
  }
  
// set value and test that it sets
  
function testSetValue() {
    
$this->test->setText("some test");
    
Assert::equalsTrue($this->test->getText() == "some text"'Value is not set');
  }
}
?>

As you can see, its really not too hard. By browsing to the index.php file, each of the Test* files and classes will be initialised and their results presented on the screen.

The next steps to this test class could be:
  • what if you tried to set the text to NULL?
  • what if you tried to set the text to ""?

The PrePostFilter tester

A new class was added to the testing framework in
order to test smarty filters. The class can actually test all filters that has the signature

<?php
$output 
filtername ($input)
?>

The class could be modified with more
to handle other kind of input-output test, but
currently only pre- and postfilters are
handleled.

Input Output tester manual

This is a description how to set up tescases for (Smarty)filters.
The 'TestBitSmartyFilter.php' is an input - output tester that feeds
the contents of a file to the function to be tested (in the first parameter)
and compares what the function returns with another file.

Right now the tester is only set up to test smarty filters in the ../kernel/smarty_tiki
directory, but testing in other directories could be aded by refactoring the code.

Follow these steps to set up a new test:

  1. Create a directory (if not allready present) that is named analogously to the filter you want to test: filtertype.filtername, e.g. prefilter.tr in the 'smarty_filter_tests' directory
  2. 'chmod' this directory so that it is writeable by your webserver, otherwise creation of the error file, useful for debugging, will not be possible.
  3. Create a file in the created directory that should be used as input for the test. Name it arbitraryname.input
  4. Run the tests by directing your browser to http://bitweaver_root/kernel/test
  5. The test will fail, since there is no arbitraryname.output file. Instead a file named arbitraryname.error will be generated. arbitraryname is the same name as in point 3.
  6. Inspect the arbitraryname.error file. If the output is the expected, you should rename the arbitraryname.error to arbitraryname.output. Running the test again (reloading the browser, should now be succesful). If the output is not the expected, correct the filter and continue from step 4.

You can add more test by creating more files in the directory created in 1.

Happy testing.

Page History
Date/CommentUserIPVersion
11 Mar 2006 (11:48 UTC)
corrected typo
Uwe Zimmermann87.96.133.21914
Current • Source
Jan Lindåker81.229.122.24913
View • Compare • Difference • Source
Jan Lindåker192.16.134.6611
View • Compare • Difference • Source
Jan Lindåker81.226.206.1989
View • Compare • Difference • Source
Stephan Borg218.214.1.1138
View • Compare • Difference • Source
Stephan Borg218.214.1.1137
View • Compare • Difference • Source
Stephan Borg218.214.1.1136
View • Compare • Difference • Source
Stephan Borg218.214.1.1135
View • Compare • Difference • Source
Stephan Borg218.214.1.1134
View • Compare • Difference • Source
Stephan Borg218.214.1.1133
View • Compare • Difference • Source
Stephan Borg218.214.1.1132
View • Compare • Difference • Source