History of TestingSuites
Version 7 | Current version | |
---|---|---|
Note: I've just discovered the PEAR::PHPUnit, which I looked at previously and didn't understand. Now it appears that it is a more effective means of testing and I will be changing the following code to suit PHPUnit rather than the script mentioned below. - wolff_borg 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. 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:
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:
| 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:
So, for our class, this is what the test class would look like:
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:
The PrePostFilter testerA new class was added to the testing framework inorder to test smarty filters. The class can actually test all filters that has the signature
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 manualThis 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:
You can add more test by creating more files in the directory created in 1. Happy testing. |