+ The heart of SimpleTest is a testing framework built around + test case classes. + These are written as extensions of base test case classes, + each extended with methods that actually contain test code. + Top level test scripts then invoke the run() + methods on every one of these test cases in order. + Each test method is written to invoke various assertions that + the developer expects to be true such as + assertEqual(). + If the expectation is correct, then a successful result is dispatched to the + observing test reporter, but any failure triggers an alert + and a description of the mismatch. +
++ A test case looks like this... +
+<?php
+class MyTestCase extends UnitTestCase {
+
+ function testLog() {
+ $log = &new Log('my.log');
+ $log->message('Hello');
+ $this->assertTrue(file_exists('my.log'));
+ }
+}
+?>
+
+
+ + These tools are designed for the developer. + Tests are written in the PHP language itself more or less + as the application itself is built. + The advantage of using PHP itself as the testing language is that + there are no new languages to learn, testing can start straight away, + and the developer can test any part of the code. + Basically, all parts that can be accessed by the application code can also be + accessed by the test code if they are in the same language. +
++ The simplest type of test case is the + UnitTestCase. + This class of test case includes standard tests for equality, + references and pattern matching. + All these test the typical expectations of what you would + expect the result of a function or method to be. + This is by far the most common type of test in the daily + routine of development, making up about 95% of test cases. +
++ The top level task of a web application though is not to + produce correct output from its methods and objects, but + to generate web pages. + The WebTestCase class tests web + pages. + It simulates a web browser requesting a page, complete with + cookies, proxies, secure connections, authentication, forms, frames and most + navigation elements. + With this type of test case, the developer can assert that + information is present in the page and that forms and + sessions are handled correctly. +
++ A WebTestCase looks like this... +
+<?php
+class MySiteTest extends WebTestCase {
+
+ function testHomePage() {
+ $this->get('http://www.my-site.com/index.php');
+ $this->assertTitle('My Home Page');
+ $this->clickLink('Contact');
+ $this->assertTitle('Contact me');
+ $this->assertWantedPattern('/Email me at/');
+ }
+}
+?>
+
+
+
+
+
+Feature list
+
+
+ The following is a very rough outline of past and future features + and their expected point of release. + I am afraid it is liable to change without warning as meeting the + milestones rather depends on time available. + Green stuff has been coded, but not necessarily released yet. + If you have a pressing need for a green but unreleased feature + then you should check-out the code from sourceforge CVS directly. + A released feature is marked as "Done". +
| Feature | Description | Release | +
|---|---|---|
| Unit test case | +Core test case class and assertions | +Done | +
| Html display | +Simplest possible display | +Done | +
| Autoloading of test cases | ++ Reading a file with test cases and loading them into a + group test automatically + | +Done | +
| Mock objects code generator | ++ Objects capable of simulating other objects removing + test dependencies + | +Done | +
| Server stubs | ++ Mocks without expectations to be used outside of test cases, + e.g. for prototyping + | +Done | +
| Integration of other unit testers | ++ The ability to read and simulate test cases from PHPUnit + and PEAR::PhpUnit + | +Done | +
| Web test case | +Basic pattern matching of fetched pages | +Done | +
| HTML parsing of pages | +Allows link following and title tag matching | +Done | +
| Partial mocks | ++ Mocking parts of a class for testing less than a class + or for complex simulations + | +Done | +
| Web cookie handling | +Correct handling of cookies when fetching pages | +Done | +
| Following redirects | +Page fetching automatically follows 300 redirects | +Done | +
| Form parsing | +Ability to submit simple forms and read default form values | +Done | +
| Command line interface | +Test display without the need of a web browser | +Done | +
| Exposure of expectation classes | +Can create precise tests with mocks as well as test cases | +Done | +
| XML output and parsing | ++ Allows multi host testing and the integration of acceptance + testing extensions + | +Done | +
| Command line test case | +Allows testing of utilities and file handling | +Done | +
| PHP Documentor compatibility | +Fully generated class level documentation | +Done | +
| Browser interface | ++ Exposure of lower level web browser interface for more + detailed test cases + | +Done | +
| HTTP authentication | ++ Fetching protected web pages with basic authentication + only + | +Done | +
| Browser navigation buttons | +Back, forward and retry | +Done | +
| SSL support | +Can connect to https: pages | +Done | +
| Proxy support | +Can connect via. common proxies | +Done | +
| Frames support | +Handling of frames in web test cases | +Done | +
| Improved display | +Better web GUI with tree display of test cases | +1.1 | +
| Localisation | +Messages abstracted and code generated from XML | +1.1 | +
| File upload testing | +Can simulate the input type file tag | +1.1 | +
| Mocking interfaces | +Can generate mock objects to interfaces as well as classes | +2.0 | +
| Testing exceptions | +Similar to testing PHP errors | +2.0 | +
| XPath searching of elements | +Can make use of HTML tidy for faster and more flexible content matching | +2.0 | +
+
+Web resources for testing
+
+
+ Process is at least as important as tools. + The type of process that makes the heaviest use of a developer's + testing tool is of course + Extreme Programming. + This is one of the + Agile Methodologies + which combine various practices to "flatten the cost curve" of software development. + More extreme still is Test Driven Development, + where you very strictly adhere to the rule of no coding until you have a test. + If you're more of a planner or believe that experience trumps evolution, + you may prefer the + RUP approach. + I haven't tried it, but even I can see that you will need test tools (see figure 9). +
++ Most unit testers clone JUnit to some degree, + as far as the interface at least. There is a wealth of information on the + JUnit site including the + FAQ + which contains plenty of general advice on testing. + Once you get bitten by the bug you will certainly appreciate the phrase + test infected + coined by Eric Gamma. + If you are still reviewing which unit tester to use the main choices + are PHPUnit + and Pear PHP::PHPUnit. + They currently lack a lot of features found in + SimpleTest, but the PEAR + version at least has been upgraded for PHP5 and is recommended if you are porting + existing JUnit test cases. +
++ Library writers don't seem to ship tests with their code very often + which is a shame. + Library code that includes tests can be more safely refactored and + the test code can act as additional documentation in a fairly standard + form. + This can save trawling the source code for clues when problems occour, + especially when upgrading such a library. + Libraries using SimpleTest for their unit testing include + WACT and + PEAR::XML_HTMLSax. +
++ There is currently a sad lack of material on mock objects, which is a shame + as unit testing without them is a lot more work. + The original mock objects paper + is very Java focused, but still worth a read. + As a new technology there are plenty of discussions and debate on how to use mocks, + often on Wikis such as + Extreme Tuesday + or www.mockobjects.com + or the original C2 Wiki. + Injecting mocks into a class is the main area of debate for which this + paper on IBM + makes a good starting point. +
++ There are plenty of web testing tools, but most are written in Java and + tutorials and advice are rather thin on the ground. + The only hope is to look at the documentation for + HTTPUnit, + HTMLUnit + or JWebUnit and hope for clues. + There are some XML driven test frameworks, but again most + require Java to run. + As SimpleTest does not support JavaScript you would probably + have to look at these tools anyway if you have highly dynamic + pages. +
+ +