History of TestingSuites

Differences from version 6 to 14



@@ -1,14 +1,20 @@

-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.
+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 [http://www.bitweaver.org/kernel/test| 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 [http://simpletest.sourceforge.net|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.
 
-The testing script we use was written by [mailto:vincent@sunlight.tmfweb.nl|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__.
+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 [mailto:vincent@sunlight.tmfweb.nl|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.
 

@@ -18,10 +24,10 @@

 # The test scripts need to include the script they will be testing (obviously).
 # Create one test class per test script, the class name being the same as the file name.
 # All test classes must extend a class Test
-# All methods within the test class beginning with the letters "test" will be executed by PHPUnit
+# 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
+{CODE source=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

@@ -31,22 +37,54 @@

  var $test;
  // initialise class and confirmed its setup correctly.
  function TestMyClass() {
- $this-&gt;test = new MyClass();
- Assert::equalsTrue(isset($this-&gt;test), 'Error during initialisation');
+ $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-&gt;test-&gt;getText() == &quot;not-set&quot;, 'Default value is not correct');
+ Assert::equalsTrue($this->test->getText() == "not-set", 'Default value is not correct');
  }
  // set value and test that it sets
  function testSetValue() {
- $this-&gt;test-&gt;setText(&quot;some test&quot;);
- Assert::equalsTrue($this-&gt;test-&gt;getText() == &quot;some text&quot;, 'Value is not set');
+ $this->test->setText("some test");
+ Assert::equalsTrue($this->test->getText() == "some text", 'Value is not set');
  }
 }
-?&gt;{CODE}
+?>{/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 &quot;&quot;?
+* 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
+{CODE source=php}$output = filtername ($input){/CODE}
+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:
+
+# 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
+# 'chmod' this directory so that it is writeable by your webserver, otherwise creation of the error file, useful for debugging, will not be possible.
+# Create a file in the created directory that should be used as input for the test. Name it ''arbitraryname''.input
+# Run the tests by directing your browser to http://''bitweaver_root''/kernel/test
+# 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.
+# 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