diff options
Diffstat (limited to 'tests/test_tools/simpletest/docs/en')
14 files changed, 0 insertions, 5605 deletions
diff --git a/tests/test_tools/simpletest/docs/en/authentication_documentation.html b/tests/test_tools/simpletest/docs/en/authentication_documentation.html deleted file mode 100755 index c90d61e5..00000000 --- a/tests/test_tools/simpletest/docs/en/authentication_documentation.html +++ /dev/null @@ -1,336 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>SimpleTest documentation for testing log-in and authentication</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<span class="chosen">Authentication</span> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Authentication documentation</h1> -<div class="content"> - - <p> - One of the trickiest, and yet most important, areas - of testing web sites is the security. - Testing these schemes is one of the core goals of - the SimpleTest web tester. - </p> - - <p> -<a class="target" name="basic"> -<h2>Basic HTTP authentication</h2> -</a> -</p> - <p> - If you fetch a page protected by basic authentication then - rather than receiving content, you will instead get a 401 - header. - We can illustrate this with this test... -<pre> -class AuthenticationTest extends WebTestCase {<strong> - function test401Header() { - $this->get('http://www.lastcraft.com/protected/'); - $this->showHeaders(); - }</strong> -} -</pre> - This allows us to see the challenge header... - <div class="demo"> - <h1>File test</h1> -<pre style="background-color: lightgray; color: black"> -HTTP/1.1 401 Authorization Required -Date: Sat, 18 Sep 2004 19:25:18 GMT -Server: Apache/1.3.29 (Unix) PHP/4.3.4 -WWW-Authenticate: Basic realm="SimpleTest basic authentication" -Connection: close -Content-Type: text/html; charset=iso-8859-1 -</pre> - <div style="padding: 8px; margin-top: 1em; background-color: green; color: white;">1/1 test cases complete. - <strong>0</strong> passes, <strong>0</strong> fails and <strong>0</strong> exceptions.</div> - </div> - We are trying to get away from visual inspection though, and so SimpleTest - allows to make automated assertions against the challenge. - Here is a thorough test of our header... -<pre> -class AuthenticationTest extends WebTestCase { - function test401Header() { - $this->get('http://www.lastcraft.com/protected/');<strong> - $this->assertAuthentication('Basic'); - $this->assertResponse(401); - $this->assertRealm('SimpleTest basic authentication');</strong> - } -} -</pre> - Any one of these tests would normally do on it's own depending - on the amount of detail you want to see. - </p> - <p> - One theme that runs through SimpleTest is the ability to use - <span class="new_code">SimpleExpectation</span> objects wherever a simple - match is not enough. - If you want only an approximate match to the realm for - example, you can do this... -<pre> -class AuthenticationTest extends WebTestCase { - function test401Header() { - $this->get('http://www.lastcraft.com/protected/'); - $this->assertRealm(<strong>new PatternExpectation('/simpletest/i')</strong>); - } -} -</pre> - Most of the time we are not interested in testing the - authentication itself, but want to get past it to test - the pages underneath. - As soon as the challenge has been issued we can reply with - an authentication response... -<pre> -class AuthenticationTest extends WebTestCase { - function testCanAuthenticate() { - $this->get('http://www.lastcraft.com/protected/');<strong> - $this->authenticate('Me', 'Secret');</strong> - $this->assertTitle(...); - } -} -</pre> - The username and password will now be sent with every - subsequent request to that directory and subdirectories. - You will have to authenticate again if you step outside - the authenticated directory, but SimpleTest is smart enough - to merge subdirectories into a common realm. - </p> - <p> - You can shortcut this step further by encoding the log in - details straight into the URL... -<pre> -class AuthenticationTest extends WebTestCase { - function testCanReadAuthenticatedPages() { - $this->get('http://<strong>Me:Secret@</strong>www.lastcraft.com/protected/'); - $this->assertTitle(...); - } -} -</pre> - If your username or password has special characters, then you - will have to URL encode them or the request will not be parsed - correctly. - Also this header will not be sent on subsequent requests if - you request a page with a fully qualified URL. - If you navigate with relative URLs though, the authentication - information will be preserved. - </p> - <p> - Only basic authentication is currently supported and this is - only really secure in tandem with HTTPS connections. - This is usually enough to protect test server from prying eyes, - however. - Digest authentication and NTLM authentication may be added - in the future. - </p> - - <p> -<a class="target" name="cookies"> -<h2>Cookies</h2> -</a> -</p> - <p> - Basic authentication doesn't give enough control over the - user interface for web developers. - More likely this functionality will be coded directly into - the web architecture using cookies and complicated timeouts. - </p> - <p> - Starting with a simple log-in form... -<pre> -<form> - Username: - <input type="text" name="u" value="" /><br /> - Password: - <input type="password" name="p" value="" /><br /> - <input type="submit" value="Log in" /> -</form> -</pre> - Which looks like... - </p> - <p> - <form class="demo"> - Username: - <input type="text" name="u" value=""> -<br> - Password: - <input type="password" name="p" value=""> -<br> - <input type="submit" value="Log in"> - </form> - </p> - <p> - Let's suppose that in fetching this page a cookie has been - set with a session ID. - We are not going to fill the form in yet, just test that - we are tracking the user. - Here is the test... -<pre> -class LogInTest extends WebTestCase { - function testSessionCookieSetBeforeForm() { - $this->get('http://www.my-site.com/login.php');<strong> - $this->assertCookie('SID');</strong> - } -} -</pre> - All we are doing is confirming that the cookie is set. - As the value is likely to be rather cryptic it's not - really worth testing this with... -<pre> -class LogInTest extends WebTestCase { - function testSessionCookieIsCorrectPattern() { - $this->get('http://www.my-site.com/login.php'); - $this->assertCookie('SID', <strong>new PatternExpectation('/[a-f0-9]{32}/i')</strong>); - } -} -</pre> - The rest of the test would be the same as any other form, - but we might want to confirm that we still have the same - cookie after log-in as before we entered. - We wouldn't want to lose track of this after all. - Here is a possible test for this... -<pre> -class LogInTest extends WebTestCase { - ... - function testSessionCookieSameAfterLogIn() { - $this->get('http://www.my-site.com/login.php');<strong> - $session = $this->getCookie('SID'); - $this->setField('u', 'Me'); - $this->setField('p', 'Secret'); - $this->click('Log in'); - $this->assertText('Welcome Me'); - $this->assertCookie('SID', $session);</strong> - } -} -</pre> - This confirms that the session identifier is maintained - afer log-in. - </p> - <p> - We could even attempt to spoof our own system by setting - arbitrary cookies to gain access... -<pre> -class LogInTest extends WebTestCase { - ... - function testSessionCookieSameAfterLogIn() { - $this->get('http://www.my-site.com/login.php');<strong> - $this->setCookie('SID', 'Some other session'); - $this->get('http://www.my-site.com/restricted.php');</strong> - $this->assertText('Access denied'); - } -} -</pre> - Is your site protected from this attack? - </p> - - <p> -<a class="target" name="session"> -<h2>Browser sessions</h2> -</a> -</p> - <p> - If you are testing an authentication system a critical piece - of behaviour is what happens when a user logs back in. - We would like to simulate closing and reopening a browser... -<pre> -class LogInTest extends WebTestCase { - ... - function testLoseAuthenticationAfterBrowserClose() { - $this->get('http://www.my-site.com/login.php'); - $this->setField('u', 'Me'); - $this->setField('p', 'Secret'); - $this->click('Log in'); - $this->assertText('Welcome Me');<strong> - - $this->restart(); - $this->get('http://www.my-site.com/restricted.php'); - $this->assertText('Access denied');</strong> - } -} -</pre> - The <span class="new_code">WebTestCase::restart()</span> method will - preserve cookies that have unexpired timeouts, but throw away - those that are temporary or expired. - You can optionally specify the time and date that the restart - happened. - </p> - <p> - Expiring cookies can be a problem. - After all, if you have a cookie that expires after an hour, - you don't want to stall the test for an hour while the - cookie passes it's timeout. - </p> - <p> - To push the cookies over the hour limit you can age them - before you restart the session... -<pre> -class LogInTest extends WebTestCase { - ... - function testLoseAuthenticationAfterOneHour() { - $this->get('http://www.my-site.com/login.php'); - $this->setField('u', 'Me'); - $this->setField('p', 'Secret'); - $this->click('Log in'); - $this->assertText('Welcome Me'); - <strong> - $this->ageCookies(3600);</strong> - $this->restart(); - $this->get('http://www.my-site.com/restricted.php'); - $this->assertText('Access denied'); - } -} -</pre> - After the restart it will appear that cookies are an - hour older and any that pass their expiry will have - disappeared. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/browser_documentation.html b/tests/test_tools/simpletest/docs/en/browser_documentation.html deleted file mode 100755 index f6046a9d..00000000 --- a/tests/test_tools/simpletest/docs/en/browser_documentation.html +++ /dev/null @@ -1,391 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>SimpleTest documentation for the scriptable web browser component</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<span class="chosen">Scriptable browser</span> -</li> -</ul> -</div> -</div> -<h1>PHP Scriptable Web Browser</h1> -<div class="content"> - - <p> - SimpleTest's web browser component can be used not just - outside of the <span class="new_code">WebTestCase</span> class, but also - independently of the SimpleTest framework itself. - </p> - - <p> -<a class="target" name="scripting"> -<h2>The Scriptable Browser</h2> -</a> -</p> - <p> - You can use the web browser in PHP scripts to confirm - services are up and running, or to extract information - from them at a regular basis. - For example, here is a small script to extract the current number of - open PHP 5 bugs from the <a href="http://www.php.net/">PHP web site</a>... -<pre> -<strong><?php - require_once('simpletest/browser.php'); - - $browser = &new SimpleBrowser(); - $browser->get('http://php.net/'); - $browser->click('reporting bugs'); - $browser->click('statistics'); - $page = $browser->click('PHP 5 bugs only'); - preg_match('/status=Open.*?by=Any.*?(\d+)<\/a>/', $page, $matches); - print $matches[1]; -?></strong> -</pre> - There are simpler methods to do this particular example in PHP - of course. - For example you can just use the PHP <span class="new_code">file()</span> - command against what here is a pretty fixed page. - However, using the web browser for scripts allows authentication, - correct handling of cookies, automatic loading of frames, redirects, - form submission and the ability to examine the page headers. - Such methods are fragile against a site that is constantly - evolving and you would want a more direct way of accessing - data in a permanent set up, but for simple tasks this can provide - a very rapid solution. - </p> - <p> - All of the navigation methods used in the - <a href="web_tester_documentation.html">WebTestCase</a> - are present in the <span class="new_code">SimpleBrowser</span> class, but - the assertions are replaced with simpler accessors. - Here is a full list of the page navigation methods... - <table> -<tbody> - <tr> -<td><span class="new_code">addHeader($header)</span></td><td>Adds a header to every fetch</td> -</tr> - <tr> -<td><span class="new_code">useProxy($proxy, $username, $password)</span></td><td>Use this proxy from now on</td> -</tr> - <tr> -<td><span class="new_code">head($url, $parameters)</span></td><td>Perform a HEAD request</td> -</tr> - <tr> -<td><span class="new_code">get($url, $parameters)</span></td><td>Fetch a page with GET</td> -</tr> - <tr> -<td><span class="new_code">post($url, $parameters)</span></td><td>Fetch a page with POST</td> -</tr> - <tr> -<td><span class="new_code">clickLink($label)</span></td><td>Follows a link by label</td> -</tr> - <tr> -<td><span class="new_code">isLink($label)</span></td><td>See if a link is present by label</td> -</tr> - <tr> -<td><span class="new_code">clickLinkById($id)</span></td><td>Follows a link by attribute</td> -</tr> - <tr> -<td><span class="new_code">isLinkById($id)</span></td><td>See if a link is present by attribut</td> -</tr> - <tr> -<td><span class="new_code">getUrl()</span></td><td>Current URL of page or frame</td> -</tr> - <tr> -<td><span class="new_code">getTitle()</span></td><td>Page title</td> -</tr> - <tr> -<td><span class="new_code">getContent()</span></td><td>Raw page or frame</td> -</tr> - <tr> -<td><span class="new_code">getContentAsText()</span></td><td>HTML removed except for alt text</td> -</tr> - <tr> -<td><span class="new_code">retry()</span></td><td>Repeat the last request</td> -</tr> - <tr> -<td><span class="new_code">back()</span></td><td>Use the browser back button</td> -</tr> - <tr> -<td><span class="new_code">forward()</span></td><td>Use the browser forward button</td> -</tr> - <tr> -<td><span class="new_code">authenticate($username, $password)</span></td><td>Retry page or frame after a 401 response</td> -</tr> - <tr> -<td><span class="new_code">restart($date)</span></td><td>Restarts the browser for a new session</td> -</tr> - <tr> -<td><span class="new_code">ageCookies($interval)</span></td><td>Ages the cookies by the specified time</td> -</tr> - <tr> -<td><span class="new_code">setCookie($name, $value)</span></td><td>Sets an additional cookie</td> -</tr> - <tr> -<td><span class="new_code">getCookieValue($host, $path, $name)</span></td><td>Reads the most specific cookie</td> -</tr> - <tr> -<td><span class="new_code">getCurrentCookieValue($name)</span></td><td>Reads cookie for the current context</td> -</tr> - </tbody> -</table> - The methods <span class="new_code">SimpleBrowser::useProxy()</span> and - <span class="new_code">SimpleBrowser::addHeader()</span> are special. - Once called they continue to apply to all subsequent fetches. - </p> - <p> - Navigating forms is similar to the - <a href="form_testing_documentation.html">WebTestCase form navigation</a>... - <table> -<tbody> - <tr> -<td><span class="new_code">setField($name, $value)</span></td><td>Sets all form fields with that name</td> -</tr> - <tr> -<td><span class="new_code">setFieldById($id, $value)</span></td><td>Sets all form fields with that id</td> -</tr> - <tr> -<td><span class="new_code">getField($name)</span></td><td>Accessor for a form element value</td> -</tr> - <tr> -<td><span class="new_code">getFieldById($id)</span></td><td>Accessor for a form element value</td> -</tr> - <tr> -<td><span class="new_code">clickSubmit($label)</span></td><td>Submits form by button label</td> -</tr> - <tr> -<td><span class="new_code">clickSubmitByName($name)</span></td><td>Submits form by button attribute</td> -</tr> - <tr> -<td><span class="new_code">clickSubmitById($id)</span></td><td>Submits form by button attribute</td> -</tr> - <tr> -<td><span class="new_code">clickImage($label, $x, $y)</span></td><td>Clicks the image by alt text</td> -</tr> - <tr> -<td><span class="new_code">clickImageByName($name, $x, $y)</span></td><td>Clicks the image by attribute</td> -</tr> - <tr> -<td><span class="new_code">clickImageById($id, $x, $y)</span></td><td>Clicks the image by attribute</td> -</tr> - <tr> -<td><span class="new_code">submitFormById($id)</span></td><td>Submits by the form tag attribute</td> -</tr> - </tbody> -</table> - At the moment there aren't any methods to list available forms - and fields. - This will probably be added to later versions of SimpleTest. - </p> - <p> - Within a page, individual frames can be selected. - If no selection is made then all the frames are merged together - in one large conceptual page. - The content of the current page will be a concatenation of all of the - frames in the order that they were specified in the "frameset" - tags. - <table> -<tbody> - <tr> -<td><span class="new_code">getFrames()</span></td><td>A dump of the current frame structure</td> -</tr> - <tr> -<td><span class="new_code">getFrameFocus()</span></td><td>Current frame label or index</td> -</tr> - <tr> -<td><span class="new_code">setFrameFocusByIndex($choice)</span></td><td>Select a frame numbered from 1</td> -</tr> - <tr> -<td><span class="new_code">setFrameFocus($name)</span></td><td>Select frame by label</td> -</tr> - <tr> -<td><span class="new_code">clearFrameFocus()</span></td><td>Treat all the frames as a single page</td> -</tr> - </tbody> -</table> - When focused on a single frame, the content will come from - that frame only. - This includes links to click and forms to submit. - </p> - - <p> -<a class="target" name="debug"> -<h2>What went wrong?</h2> -</a> -</p> - <p> - All of this functionality is great when we actually manage to fetch pages, - but that doesn't always happen. - To help figure out what went wrong, the browser has some methods to - aid in debugging... - <table> -<tbody> - <tr> -<td><span class="new_code">setConnectionTimeout($timeout)</span></td><td>Close the socket on overrun</td> -</tr> - <tr> -<td><span class="new_code">getRequest()</span></td><td>Raw request header of page or frame</td> -</tr> - <tr> -<td><span class="new_code">getHeaders()</span></td><td>Raw response header of page or frame</td> -</tr> - <tr> -<td><span class="new_code">getTransportError()</span></td><td>Any socket level errors in the last fetch</td> -</tr> - <tr> -<td><span class="new_code">getResponseCode()</span></td><td>HTTP response of page or frame</td> -</tr> - <tr> -<td><span class="new_code">getMimeType()</span></td><td>Mime type of page or frame</td> -</tr> - <tr> -<td><span class="new_code">getAuthentication()</span></td><td>Authentication type in 401 challenge header</td> -</tr> - <tr> -<td><span class="new_code">getRealm()</span></td><td>Authentication realm in 401 challenge header</td> -</tr> - <tr> -<td><span class="new_code">setMaximumRedirects($max)</span></td><td>Number of redirects before page is loaded anyway</td> -</tr> - <tr> -<td><span class="new_code">setMaximumNestedFrames($max)</span></td><td>Protection against recursive framesets</td> -</tr> - <tr> -<td><span class="new_code">ignoreFrames()</span></td><td>Disables frames support</td> -</tr> - <tr> -<td><span class="new_code">useFrames()</span></td><td>Enables frames support</td> -</tr> - <tr> -<td><span class="new_code">ignoreCookies()</span></td><td>Disables sending and receiving of cookies</td> -</tr> - <tr> -<td><span class="new_code">useCookies()</span></td><td>Enables cookie support</td> -</tr> - </tbody> -</table> - The methods <span class="new_code">SimpleBrowser::setConnectionTimeout()</span> - <span class="new_code">SimpleBrowser::setMaximumRedirects()</span>, - <span class="new_code">SimpleBrowser::setMaximumNestedFrames()</span>, - <span class="new_code">SimpleBrowser::ignoreFrames()</span>, - <span class="new_code">SimpleBrowser::useFrames()</span>, - <span class="new_code">SimpleBrowser::ignoreCookies()</span> and - <span class="new_code">SimpleBrowser::useCokies()</span> continue to apply - to every subsequent request. - The other methods are frames aware. - This means that if you have an individual frame that is not - loading, navigate to it using <span class="new_code">SimpleBrowser::setFrameFocus()</span> - and you can then use <span class="new_code">SimpleBrowser::getRequest()</span>, etc to - see what happened. - </p> - - <p> -<a class="target" name="unit"> -<h2>Complex unit tests with multiple browsers</h2> -</a> -</p> - <p> - Anything that could be done in a - <a href="web_tester_documentation.html">WebTestCase</a> can - now be done in a <a href="unit_tester_documentation.html">UnitTestCase</a>. - This means that we can freely mix domain object testing with the - web interface... -<pre> -<strong> -class TestOfRegistration extends UnitTestCase { - function testNewUserAddedToAuthenticator() {</strong> - $browser = &new SimpleBrowser(); - $browser->get('http://my-site.com/register.php'); - $browser->setField('email', 'me@here'); - $browser->setField('password', 'Secret'); - $browser->click('Register'); - <strong> - $authenticator = &new Authenticator(); - $member = &$authenticator->findByEmail('me@here'); - $this->assertEqual($member->getPassword(), 'Secret'); - } -}</strong> -</pre> - While this may be a useful temporary expediency, I am not a fan - of this type of testing. - The testing has cut across application layers, make it twice as - likely it will need refactoring when the code changes. - </p> - <p> - A more useful case of where using the browser directly can be helpful - is where the <span class="new_code">WebTestCase</span> cannot cope. - An example is where two browsers are needed at the same time. - </p> - <p> - For example, say we want to disallow multiple simultaneous - usage of a site with the same username. - This test case will do the job... -<pre> -class TestOfSecurity extends UnitTestCase { - function testNoMultipleLoginsFromSameUser() {<strong> - $first = &new SimpleBrowser(); - $first->get('http://my-site.com/login.php'); - $first->setField('name', 'Me'); - $first->setField('password', 'Secret'); - $first->click('Enter'); - $this->assertEqual($first->getTitle(), 'Welcome'); - - $second = &new SimpleBrowser(); - $second->get('http://my-site.com/login.php'); - $second->setField('name', 'Me'); - $second->setField('password', 'Secret'); - $second->click('Enter'); - $this->assertEqual($second->getTitle(), 'Access Denied');</strong> - } -} -</pre> - You can also use the <span class="new_code">SimpleBrowser</span> class - directly when you want to write test cases using a different - test tool than SimpleTest. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/docs.css b/tests/test_tools/simpletest/docs/en/docs.css deleted file mode 100755 index 93226cd7..00000000 --- a/tests/test_tools/simpletest/docs/en/docs.css +++ /dev/null @@ -1,84 +0,0 @@ -body { - padding-left: 3%; - padding-right: 3%; -} -pre { - font-family: courier; - font-size: 80%; - border: 1px solid; - background-color: #cccccc; - padding: 5px; - margin-left: 5%; - margin-right: 8%; -} -.code, .new_code, pre.new_code { - font-weight: bold; -} -div.copyright { - font-size: 80%; - color: gray; -} -div.copyright a { - color: gray; -} -ul.api { - padding-left: 0em; - padding-right: 25%; -} -ul.api li { - margin-top: 0.2em; - margin-bottom: 0.2em; - list-style: none; - text-indent: -3em; - padding-left: 3em; -} -div.demo { - border: 4px ridge; - border-color: gray; - padding: 10px; - margin: 5px; - margin-left: 20px; - margin-right: 40px; - background-color: white; -} -div.demo span.fail { - color: red; -} -div.demo span.pass { - color: green; -} -div.demo h1 { - font-size: 12pt; - text-align: left; - font-weight: bold; -} -table { - border: 2px outset; - border-color: gray; - background-color: white; - margin: 5px; - margin-left: 5%; - margin-right: 5%; -} -td { - font-size: 80%; -} -.shell { - color: white; -} -pre.shell { - border: 4px ridge; - border-color: gray; - padding: 10px; - margin: 5px; - margin-left: 20px; - margin-right: 40px; - background-color: black; -} -form.demo { - background-color: lightgray; - border: 4px outset; - border-color: lightgray; - padding: 10px; - margin-right: 40%; -} diff --git a/tests/test_tools/simpletest/docs/en/expectation_documentation.html b/tests/test_tools/simpletest/docs/en/expectation_documentation.html deleted file mode 100755 index bd189b94..00000000 --- a/tests/test_tools/simpletest/docs/en/expectation_documentation.html +++ /dev/null @@ -1,346 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title> - Extending the SimpleTest unit tester with additional expectation classes - </title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<span class="chosen">Expectations</span> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Expectation documentation</h1> -<div class="content"> - <p> -<a class="target" name="mock"> -<h2>More control over mock objects</h2> -</a> -</p> - <p> - The default behaviour of the - <a href="mock_objects_documentation.html">mock objects</a> - in - <a href="http://sourceforge.net/projects/simpletest/">SimpleTest</a> - is either an identical match on the argument or to allow any argument at all. - For almost all tests this is sufficient. - Sometimes, though, you want to weaken a test case. - </p> - <p> - One place where a test can be too tightly coupled is with - text matching. - Suppose we have a component that outputs a helpful error - message when something goes wrong. - You want to test that the correct error was sent, but the actual - text may be rather long. - If you test for the text exactly, then every time the exact wording - of the message changes, you will have to go back and edit the test suite. - </p> - <p> - For example, suppose we have a news service that has failed - to connect to its remote source. -<pre> -<strong>class NewsService { - ... - function publish(&$writer) { - if (! $this->isConnected()) { - $writer->write('Cannot connect to news service "' . - $this->_name . '" at this time. ' . - 'Please try again later.'); - } - ... - } -}</strong> -</pre> - Here it is sending its content to a - <span class="new_code">Writer</span> class. - We could test this behaviour with a - <span class="new_code">MockWriter</span> like so... -<pre> -class TestOfNewsService extends UnitTestCase { - ... - function testConnectionFailure() {<strong> - $writer = &new MockWriter(); - $writer->expectOnce('write', array( - 'Cannot connect to news service ' . - '"BBC News" at this time. ' . - 'Please try again later.')); - - $service = &new NewsService('BBC News'); - $service->publish($writer); - } -} -</pre> - This is a good example of a brittle test. - If we decide to add additional instructions, such as - suggesting an alternative news source, we will break - our tests even though no underlying functionality - has been altered. - </p> - <p> - To get around this, we would like to do a regular expression - test rather than an exact match. - We can actually do this with... -<pre> -class TestOfNewsService extends UnitTestCase { - ... - function testConnectionFailure() { - $writer = &new MockWriter();<strong> - $writer->expectOnce( - 'write', - array(new PatternExpectation('/cannot connect/i')));</strong> - - $service = &new NewsService('BBC News'); - $service->publish($writer); - } -} -</pre> - Instead of passing in the expected parameter to the - <span class="new_code">MockWriter</span> we pass an - expectation class called - <span class="new_code">WantedPatternExpectation</span>. - The mock object is smart enough to recognise this as special - and to treat it differently. - Rather than simply comparing the incoming argument to this - object, it uses the expectation object itself to - perform the test. - </p> - <p> - The <span class="new_code">WantedPatternExpectation</span> takes - the regular expression to match in its constructor. - Whenever a comparison is made by the <span class="new_code">MockWriter</span> - against this expectation class, it will do a - <span class="new_code">preg_match()</span> with this pattern. - With our test case above, as long as "cannot connect" - appears in the text of the string, the mock will issue a pass - to the unit tester. - The rest of the text does not matter. - </p> - <p> - The possible expectation classes are... - <table> -<tbody> - <tr> -<td><span class="new_code">EqualExpectation</span></td><td>An equality, rather than the stronger identity comparison</td> -</tr> - <tr> -<td><span class="new_code">NotEqualExpectation</span></td><td>An inequality comparison</td> -</tr> - <tr> -<td><span class="new_code">IndenticalExpectation</span></td><td>The default mock object check which must match exactly</td> -</tr> - <tr> -<td><span class="new_code">NotIndenticalExpectation</span></td><td>Inverts the mock object logic</td> -</tr> - <tr> -<td><span class="new_code">PatternExpectation</span></td><td>Uses a Perl Regex to match a string</td> -</tr> - <tr> -<td><span class="new_code">NoPatternExpectation</span></td><td>Passes only if failing a Perl Regex</td> -</tr> - <tr> -<td><span class="new_code">IsAExpectation</span></td><td>Checks the type or class name only</td> -</tr> - <tr> -<td><span class="new_code">NotAExpectation</span></td><td>Opposite of the <span class="new_code">IsAExpectation</span></td> -</tr> - <tr> -<td><span class="new_code">MethodExistsExpectation</span></td><td>Checks a method is available on an object</td> -</tr> - </tbody> -</table> - Most take the expected value in the constructor. - The exceptions are the pattern matchers, which take a regular expression, - and the <span class="new_code">IsAExpectation</span> and <span class="new_code">NotAExpectation</span> which takes a type - or class name as a string. - </p> - - <p> -<a class="target" name="behaviour"> -<h2>Using expectations to control stubs</h2> -</a> -</p> - <p> - The expectation classes can be used not just for sending assertions - from mock objects, but also for selecting behaviour for the - <a href="mock_objects_documentation.html">mock objects</a>. - Anywhere a list of arguments is given, a list of expectation objects - can be inserted instead. - </p> - <p> - Suppose we want an authorisation server mock to simulate a successful login - only if it receives a valid session object. - We can do this as follows... -<pre> -Mock::generate('Authorisation'); -<strong> -$authorisation = new MockAuthorisation(); -$authorisation->setReturnValue( - 'isAllowed', - true, - array(new IsAExpectation('Session', 'Must be a session'))); -$authorisation->setReturnValue('isAllowed', false);</strong> -</pre> - We have set the default mock behaviour to return false when - <span class="new_code">isAllowed</span> is called. - When we call the method with a single parameter that - is a <span class="new_code">Session</span> object, it will return true. - We have also added a second parameter as a message. - This will be displayed as part of the mock object - failure message if this expectation is the cause of - a failure. - </p> - <p> - This kind of sophistication is rarely useful, but is included for - completeness. - </p> - - <p> -<a class="target" name="extending"> -<h2>Creating your own expectations</h2> -</a> -</p> - <p> - The expectation classes have a very simple structure. - So simple that it is easy to create your own versions for - commonly used test logic. - </p> - <p> - As an example here is the creation of a class to test for - valid IP addresses. - In order to work correctly with the stubs and mocks the new - expectation class should extend - <span class="new_code">SimpleExpectation</span>... -<pre> -<strong>class ValidIp extends SimpleExpectation { - - function test($ip) { - return (ip2long($ip) != -1); - } - - function testMessage($ip) { - return "Address [$ip] should be a valid IP address"; - } -}</strong> -</pre> - There are only two methods to implement. - The <span class="new_code">test()</span> method should - evaluate to true if the expectation is to pass, and - false otherwise. - The <span class="new_code">testMessage()</span> method - should simply return some helpful text explaining the test - that was carried out. - </p> - <p> - This class can now be used in place of the earlier expectation - classes. - </p> - - <p> -<a class="target" name="unit"> -<h2>Under the bonnet of the unit tester</h2> -</a> -</p> - <p> - The <a href="http://sourceforge.net/projects/simpletest/">SimpleTest unit testing framework</a> - also uses the expectation classes internally for the - <a href="unit_test_documentation.html">UnitTestCase class</a>. - We can also take advantage of these mechanisms to reuse our - homebrew expectation classes within the test suites directly. - </p> - <p> - The most crude way of doing this is to use the - <span class="new_code">SimpleTest::assert()</span> method to - test against it directly... -<pre> -<strong>class TestOfNetworking extends UnitTestCase { - ... - function testGetValidIp() { - $server = &new Server(); - $this->assert( - new ValidIp(), - $server->getIp(), - 'Server IP address->%s'); - } -}</strong> -</pre> - This is a little untidy compared with our usual - <span class="new_code">assert...()</span> syntax. - </p> - <p> - For such a simple case we would normally create a - separate assertion method on our test case rather - than bother using the expectation class. - If we pretend that our expectation is a little more - complicated for a moment, so that we want to reuse it, - we get... -<pre> -class TestOfNetworking extends UnitTestCase { - ...<strong> - function assertValidIp($ip, $message = '%s') { - $this->assert(new ValidIp(), $ip, $message); - }</strong> - - function testGetValidIp() { - $server = &new Server();<strong> - $this->assertValidIp( - $server->getIp(), - 'Server IP address->%s');</strong> - } -} -</pre> - It is unlikely we would ever need this degree of control - over the testing machinery. - It is rare to need the expectations for more than pattern - matching. - Also, complex expectation classes could make the tests - harder to read and debug. - These mechanisms are really of most use to authors of systems - that will extend the test framework to create their own tool set. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/form_testing_documentation.html b/tests/test_tools/simpletest/docs/en/form_testing_documentation.html deleted file mode 100755 index 50b634c0..00000000 --- a/tests/test_tools/simpletest/docs/en/form_testing_documentation.html +++ /dev/null @@ -1,276 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>Simple Test documentation for testing HTML forms</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<span class="chosen">Testing forms</span> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Form testing documentation</h1> -<div class="content"> - <p> -<a class="target" name="submit"> -<h2>Submitting a simple form</h2> -</a> -</p> - <p> - When a page is fetched by the <span class="new_code">WebTestCase</span> - using <span class="new_code">get()</span> or - <span class="new_code">post()</span> the page content is - automatically parsed. - This results in any form controls that are inside <form> tags - being available from within the test case. - For example, if we have this snippet of HTML... -<pre> -<form> - <input type="text" name="a" value="A default" /> - <input type="submit" value="Go" /> -</form> -</pre> - Which looks like this... - </p> - <p> - <form class="demo"> - <input type="text" name="a" value="A default"> - <input type="submit" value="Go"> - </form> - </p> - <p> - We can navigate to this code, via the - <a href="http://www.lastcraft.com/form_testing_documentation.php">LastCraft</a> - site, with the following test... -<pre> -class SimpleFormTests extends WebTestCase { - <strong> - function testDefaultValue() { - $this->get('http://www.lastcraft.com/form_testing_documentation.php'); - $this->assertField('a', 'A default'); - }</strong> -} -</pre> - Immediately after loading the page all of the HTML controls are set at - their default values just as they would appear in the web browser. - The assertion tests that a HTML widget exists in the page with the - name "a" and that it is currently set to the value - "A default". - As usual, we could use a pattern expectation instead if a fixed - string. - </p> - <p> - We could submit the form straight away, but first we'll change - the value of the text field and only then submit it... -<pre> -class SimpleFormTests extends WebTestCase { - - function testDefaultValue() { - $this->get('http://www.my-site.com/'); - $this->assertField('a', 'A default');<strong> - $this->setField('a', 'New value'); - $this->click('Go');</strong> - } -} -</pre> - Because we didn't specify a method attribute on the form tag, and - didn't specify an action either, the test case will follow - the usual browser behaviour of submitting the form data as a <em>GET</em> - request back to the same location. - SimpleTest tries to emulate typical browser behaviour as much as possible, - rather than attempting to catch missing attributes on tags. - This is because the target of the testing framework is the PHP application - logic, not syntax or other errors in the HTML code. - For HTML errors, other tools such as - <a href="http://www.w3.org/People/Raggett/tidy/">HTMLTidy</a> should be used. - </p> - <p> - If a field is not present in any form, or if an option is unavailable, - then <span class="new_code">WebTestCase::setField()</span> will return - <span class="new_code">false</span>. - For example, suppose we wish to verify that a "Superuser" - option is not present in this form... -<pre> -<strong>Select type of user to add:</strong> -<select name="type"> - <option>Subscriber</option> - <option>Author</option> - <option>Administrator</option> -</select> -</pre> - Which looks like... - </p> - <p> - <form class="demo"> - <strong>Select type of user to add:</strong> - <select name="type"> - <option>Subscriber</option> - <option>Author</option> - <option>Administrator</option> - </select> - </form> - </p> - <p> - The following test will confirm it... -<pre> -class SimpleFormTests extends WebTestCase { - ... - function testNoSuperuserChoiceAvailable() {<strong> - $this->get('http://www.lastcraft.com/form_testing_documentation.php'); - $this->assertFalse($this->setField('type', 'Superuser'));</strong> - } -} -</pre> - The selection will not be changed on a failure to set - a widget value. - </p> - <p> - Here is the full list of widgets currently supported... - <ul> - <li>Text fields, including hidden and password fields.</li> - <li>Submit buttons including the button tag, although not yet reset buttons</li> - <li>Text area. This includes text wrapping behaviour.</li> - <li>Checkboxes, including multiple checkboxes in the same form.</li> - <li>Drop down selections, including multiple selects.</li> - <li>Radio buttons.</li> - <li>Images.</li> - </ul> - </p> - <p> - Although most standard HTML widgets are catered for by <em>SimpleTest</em>'s - built in parser, it is unlikely that JavaScript will be implemented - anytime soon. - </p> - - <p> -<a class="target" name="multiple"> -<h2>Fields with multiple values</h2> -</a> -</p> - <p> - SimpleTest can cope with two types of multivalue controls: Multiple - selection drop downs, and multiple checkboxes with the same name - within a form. - The multivalue nature of these means that setting and testing - are slightly different. - Using checkboxes as an example... -<pre> -<form class="demo"> - <strong>Create privileges allowed:</strong> - <input type="checkbox" name="crud" value="c" checked><br> - <strong>Retrieve privileges allowed:</strong> - <input type="checkbox" name="crud" value="r" checked><br> - <strong>Update privileges allowed:</strong> - <input type="checkbox" name="crud" value="u" checked><br> - <strong>Destroy privileges allowed:</strong> - <input type="checkbox" name="crud" value="d" checked><br> - <input type="submit" value="Enable Privileges"> -</form> -</pre> - Which renders as... - </p> - <p> - <form class="demo"> - <strong>Create privileges allowed:</strong> - <input type="checkbox" name="crud" value="c" checked> -<br> - <strong>Retrieve privileges allowed:</strong> - <input type="checkbox" name="crud" value="r" checked> -<br> - <strong>Update privileges allowed:</strong> - <input type="checkbox" name="crud" value="u" checked> -<br> - <strong>Destroy privileges allowed:</strong> - <input type="checkbox" name="crud" value="d" checked> -<br> - <input type="submit" value="Enable Privileges"> - </form> - </p> - <p> - If we wish to disable all but the retrieval privileges and - submit this information we can do it like this... -<pre> -class SimpleFormTests extends WebTestCase { - ...<strong> - function testDisableNastyPrivileges() { - $this->get('http://www.lastcraft.com/form_testing_documentation.php'); - $this->assertField('crud', array('c', 'r', 'u', 'd')); - $this->setField('crud', array('r')); - $this->click('Enable Privileges'); - }</strong> -} -</pre> - Instead of setting the field to a single value, we give it a list - of values. - We do the same when testing expected values. - We can then write other test code to confirm the effect of this, perhaps - by logging in as that user and attempting an update. - </p> - <p> - <a class="target" name="raw"> -<h2>Raw posting</h2> -</a> - </p> - <p> - If you want to test a form handler, but have not yet written - or do not have access to the form itself, you can create a - form submission by hand. -<pre> -class SimpleFormTests extends WebTestCase { - ...<strong> - function testAttemptedHack() { - $this->post( - 'http://www.my-site.com/add_user.php', - array('type' => 'superuser')); - $this->assertNoText('user created'); - }</strong> -} -</pre> - By adding data to the <span class="new_code">WebTestCase::post()</span> - method, we are attempting to fetch the page as a form submission. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/group_test_documentation.html b/tests/test_tools/simpletest/docs/en/group_test_documentation.html deleted file mode 100755 index 1e14d31e..00000000 --- a/tests/test_tools/simpletest/docs/en/group_test_documentation.html +++ /dev/null @@ -1,354 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>SimpleTest for PHP group test documentation</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<span class="chosen">Group tests</span> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Group Test documentation</h1> -<div class="content"> - <p> -<a class="target" name="group"> -<h2>Grouping tests</h2> -</a> -</p> - <p> - To run test cases as part of a group the test cases should really - be placed in files without the runner code... -<pre> -<strong><?php - require_once('../classes/io.php'); - - class FileTester extends UnitTestCase { - ... - } - - class SocketTester extends UnitTestCase { - ... - } -?></strong> -</pre> - As many cases as needed can appear in a single file. - They should include any code they need, such as the library - being tested, but none of the simple test libraries. - </p> - <p> - If you have extended any test cases, you can include them - as well. -<pre> -<?php - require_once('../classes/io.php'); -<strong> - class MyFileTestCase extends UnitTestCase { - ... - } - SimpleTest::ignore('MyFileTestCase');</strong> - - class FileTester extends MyFileTestCase { - ... - } - - class SocketTester extends UnitTestCase { - ... - } -?> -</pre> - The <span class="new_code">FileTester</span> class does - not contain any actual tests, but is a base class for other - test cases. - For this reason we use the - <span class="new_code">SimpleTestOptions::ignore()</span> directive - to tell the upcoming group test to ignore it. - This directive can appear anywhere in the file and works - when a whole file of test cases is loaded (see below). - We will call this sample <em>file_test.php</em>. - </p> - <p> - Next we create a group test file, called say <em>group_test.php</em>. - You will think of a better name I am sure. - We will add the test file using a safe method... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php');<strong> - require_once('file_test.php'); - - $test = &new GroupTest('All file tests'); - $test->addTestCase(new FileTestCase()); - $test->run(new HtmlReporter());</strong> -?> -</pre> - This instantiates the test case before the test suite is - run. - This could get a little expensive with a large number of test - cases, so another method is provided that will only - instantiate the class when it is needed... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php'); - require_once('file_test.php'); - - $test = &new GroupTest('All file tests');<strong> - $test->addTestClass('FileTestCase');</strong> - $test->run(new HtmlReporter()); -?> -</pre> - The problem with this method is that for every test case - that we add we will have - to <span class="new_code">require_once()</span> the test code - file and manually instantiate each and every test case. - We can save a lot of typing with... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php'); - - $test = &new GroupTest('All file tests');<strong> - $test->addTestFile('file_test.php');</strong> - $test->run(new HtmlReporter()); -?&gt; -</pre> - What happens here is that the <span class="new_code">GroupTest</span> - class has done the <span class="new_code">require_once()</span> - for us. - It then checks to see if any new test case classes - have been created by the new file and automatically adds - them to the group test. - Now all we have to do is add each new file. - </p> - <p> - There are two things that could go wrong and which require care... - <ol> - <li> - The file could already have been parsed by PHP and so no - new classes will have been added. You should make - sure that the test cases are only included in this file - and no others. - </li> - <li> - New test case extension classes that get included will be - placed in the group test and run also. - You will need to add a <span class="new_code">SimpleTestOptions::ignore()</span> - directive for these classes or make sure that they are included - before the <span class="new_code">GroupTest::addTestFile()</span> - line. - </li> - </ol> - </p> - - <p> -<a class="target" name="higher"> -<h2>Higher groupings</h2> -</a> -</p> - <p> - The above method places all of the test cases into one large group. - For larger projects though this may not be flexible enough; you - may want to group the tests in all sorts of ways. - </p> - <p> - To get a more flexible group test we can subclass - <span class="new_code">GroupTest</span> and then instantiate it as needed... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php'); - <strong> - class FileGroupTest extends GroupTest { - function FileGroupTest() { - $this->GroupTest('All file tests'); - $this->addTestFile('file_test.php'); - } - }</strong> -?> -</pre> - This effectively names the test in the constructor and then - adds our test cases and a single group below. - Of course we can add more than one group at this point. - We can now invoke the tests from a separate runner file... -<pre> -<?php - require_once('file_group_test.php'); - <strong> - $test = &new FileGroupTest(); - $test->run(new HtmlReporter());</strong> -?> -</pre> - ...or we can group them into even larger group tests... -<pre> -<?php - require_once('file_group_test.php'); - <strong> - $test = &new BigGroupTest('Big group'); - $test->addTestCase(new FileGroupTest()); - $test->addTestCase(...); - $test->run(new HtmlReporter());</strong> -?> -</pre> - If we still wish to run the original group test and we - don't want all of these little runner files, we can - put the test runner code around guard bars when we create - each group. -<pre> -<?php - class FileGroupTest extends GroupTest { - function FileGroupTest() { - $this->GroupTest('All file tests'); - $test->addTestFile('file_test.php'); - } - } - <strong> - if (! defined('RUNNER')) { - define('RUNNER', true);</strong> - $test = &new FileGroupTest(); - $test->run(new HtmlReporter()); - } -?> -</pre> - This approach requires the guard to be set when including - the group test file, but this is still less hassle than - lots of separate runner files. - You include the same guard on the top level tests to make sure - that <span class="new_code">run()</span> will run once only - from the top level script that has been invoked. -<pre> -<?php<strong> - define('RUNNER', true);</strong> - require_once('file_group_test.php'); - - $test = &new BigGroupTest('Big group'); - $test->addTestCase(new FileGroupTest()); - $test->addTestCase(...); - $test->run(new HtmlReporter()); -?> -</pre> - As with the normal test cases, a <span class="new_code">GroupTest</span> can - be loaded with the <span class="new_code">GroupTest::addTestFile()</span> method. -<pre> -<?php - define('RUNNER', true); - - $test = &new BigGroupTest('Big group');<strong> - $test->addTestFile('file_group_test.php'); - $test->addTestFile(...);</strong> - $test->run(new HtmlReporter()); -?> -</pre> - </p> - - <p> -<a class="target" name="legacy"> -<h2>Integrating legacy test cases</h2> -</a> -</p> - <p> - If you already have unit tests for your code or are extending external - classes that have tests, it is unlikely that all of the test cases - are in SimpleTest format. - Fortunately it is possible to incorporate test cases from other - unit testers directly into SimpleTest group tests. - </p> - <p> - Say we have the following - <a href="http://sourceforge.net/projects/phpunit">PhpUnit</a> - test case in the file <em>config_test.php</em>... -<pre> -<strong>class ConfigFileTest extends TestCase { - function ConfigFileTest() { - $this->TestCase('Config file test'); - } - - function testContents() { - $config = new ConfigFile('test.conf'); - $this->assertRegexp('/me/', $config->getValue('username')); - } -}</strong> -</pre> - The group test can recognise this as long as we include - the appropriate adapter class before we add the test - file... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php');<strong> - require_once('simpletest/adapters/phpunit_test_case.php');</strong> - - $test = &new GroupTest('All file tests');<strong> - $test->addTestFile('config_test.php');</strong> - $test->run(new HtmlReporter()); -?> -</pre> - There are only two adapters, the other is for the - <a href="http://pear.php.net/manual/en/package.php.phpunit.php">PEAR</a> - 1.0 unit tester... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php');<strong> - require_once('simpletest/adapters/pear_test_case.php');</strong> - - $test = &new GroupTest('All file tests');<strong> - $test->addTestFile('some_pear_test_cases.php');</strong> - $test->run(new HtmlReporter()); -?> -</pre> - The PEAR test cases can be freely mixed with SimpleTest - ones even in the same test file, - but you cannot use SimpleTest assertions in the legacy - test case versions. - This is done as a check that you are not accidently making - your test cases completely dependent on SimpleTest. - You may want to do a PEAR release of your library for example - which would mean shipping it with valid PEAR::PhpUnit test - cases. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/index.html b/tests/test_tools/simpletest/docs/en/index.html deleted file mode 100755 index c7183c49..00000000 --- a/tests/test_tools/simpletest/docs/en/index.html +++ /dev/null @@ -1,461 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title> - Download the Simple Test testing framework - - Unit tests and mock objects for PHP - </title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<span class="chosen">SimpleTest</span> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Simple Test for PHP</h1> -<div class="content"> - - - <p> - The following assumes that you are familiar with the concept - of unit testing as well as the PHP web development language. - It is a guide for the impatient new user of - <a href="https://sourceforge.net/project/showfiles.php?group_id=76550">SimpleTest</a>. - For fuller documentation, especially if you are new - to unit testing see the ongoing - <a href="unit_test_documentation.html">documentation</a>, and for - example test cases see the - <a href="http://www.lastcraft.com/first_test_tutorial.php">unit testing tutorial</a>. - </p> - - <p> -<a class="target" name="unit"> -<h2>Using the tester quickly</h2> -</a> -</p> - <p> - Amongst software testing tools, a unit tester is the one - closest to the developer. - In the context of agile development the test code sits right - next to the source code as both are written simultaneously. - In this context SimpleTest aims to be a complete PHP developer - test solution and is called "Simple" because it - should be easy to use and extend. - It wasn't a good choice of name really. - It includes all of the typical functions you would expect from - <a href="http://www.junit.org/">JUnit</a> and the - <a href="http://sourceforge.net/projects/phpunit/">PHPUnit</a> - ports, but also adds - <a href="http://www.mockobjects.com">mock objects</a>. - It has some <a href="http://sourceforge.net/projects/jwebunit/">JWebUnit</a> - functionality as well. - This includes web page navigation, cookie testing and form submission. - </p> - <p> - The quickest way to demonstrate is with an example. - </p> - <p> - Let us suppose we are testing a simple file logging class called - <span class="new_code">Log</span> in <em>classes/log.php</em>. - We start by creating a test script which we will call - <em>tests/log_test.php</em> and populate it as follows... -<pre> -<?php<strong> -require_once('simpletest/unit_tester.php'); -require_once('simpletest/reporter.php'); -require_once('../classes/log.php'); - -class TestOfLogging extends UnitTestCase { -}</strong> -?> -</pre> - Here the <em>simpletest</em> folder is either local or in the path. - You would have to edit these locations depending on where you - placed the toolset. - The <span class="new_code">TestOfLogging</span> is our frst test case and it's - currently empty. - </p> - <p> - Now we have five lines of scaffolding code and still no tests. - However from this part on we get return on our investment very quickly. - We'll assume that the <span class="new_code">Log</span> class - takes the file name to write to in the constructor and we have - a temporary folder in which to place this file... -<pre> -<?php -require_once('simpletest/unit_tester.php'); -require_once('simpletest/reporter.php'); -require_once('../classes/log.php'); - -class TestOfLogging extends UnitTestCase { - <strong> - function testCreatingNewFile() { - @unlink('/temp/test.log'); - $log = new Log('/temp/test.log'); - $this->assertFalse(file_exists('/temp/test.log')); - $log->message('Should write this to a file'); - $this->assertTrue(file_exists('/temp/test.log')); - }</strong> -} -?> -</pre> - When a test case runs it will search for any method that - starts with the string <span class="new_code">test</span> - and execute that method. - We would normally have more than one test method of course. - Assertions within the test methods trigger messages to the - test framework which displays the result immediately. - This immediate response is important, not just in the event - of the code causing a crash, but also so that - <span class="new_code">print</span> statements can display - their content right next to the test case concerned. - </p> - <p> - To see these results we have to actually run the tests. - If this is the only test case we wish to run we can achieve - it with... -<pre> -<?php -require_once('simpletest/unit_tester.php'); -require_once('simpletest/reporter.php'); -require_once('../classes/log.php'); - -class TestOfLogging extends UnitTestCase { - - function testCreatingNewFile() { - @unlink('/temp/test.log'); - $log = new Log('/temp/test.log'); - $this->assertFalse(file_exists('/temp/test.log')); - $log->message('Should write this to a file'); - $this->assertTrue(file_exists('/temp/test.log')); - } -} -<strong> -$test = &new TestOfLogging(); -$test->run(new HtmlReporter());</strong> -?> -</pre> - </p> - <p> - On failure the display looks like this... - <div class="demo"> - <h1>testoflogging</h1> - <span class="fail">Fail</span>: testcreatingnewfile->True assertion failed.<br> - <div style="padding: 8px; margin-top: 1em; background-color: red; color: white;">1/1 test cases complete. - <strong>1</strong> passes and <strong>1</strong> fails.</div> - </div> - ...and if it passes like this... - <div class="demo"> - <h1>testoflogging</h1> - <div style="padding: 8px; margin-top: 1em; background-color: green; color: white;">1/1 test cases complete. - <strong>2</strong> passes and <strong>0</strong> fails.</div> - </div> - And if you get this... - <div class="demo"> - <b>Fatal error</b>: Failed opening required '../classes/log.php' (include_path='') in <b>/home/marcus/projects/lastcraft/tutorial_tests/Log/tests/log_test.php</b> on line <b>7</b> - </div> - it means you're missing the <em>classes/Log.php</em> file that could look like... -<pre> -<?php -class Log { - - function Log($file_path) { - } - - function message() { - } -} -?>; -</pre> - </p> - - <p> -<a class="target" name="group"> -<h2>Building group tests</h2> -</a> -</p> - <p> - It is unlikely in a real application that we will only ever run - one test case. - This means that we need a way of grouping cases into a test - script that can, if need be, run every test in the application. - </p> - <p> - Our first step is to strip the includes and to undo our - previous hack... -<pre> -<?php<strong> -require_once('../classes/log.php');</strong> - -class TestOfLogging extends UnitTestCase { - - function testCreatingNewFile() { - @unlink('/temp/test.log'); - $log = new Log('/temp/test.log'); - $this->assertFalse(file_exists('/temp/test.log')); - $log->message('Should write this to a file'); - $this->assertTrue(file_exists('/temp/test.log'));<strong> - } -} -?></strong> -</pre> - Next we create a new file called <em>tests/all_tests.php</em> - and insert the following code... -<pre> -<strong><?php -require_once('simpletest/unit_tester.php'); -require_once('simpletest/reporter.php'); - -$test = &new GroupTest('All tests'); -$test->addTestFile('log_test.php'); -$test->run(new HtmlReporter()); -?></strong> -</pre> - The method <span class="new_code">GroupTest::addTestFile()</span> - will include the test case file and read any new classes created - that are descended from <span class="new_code">SimpleTestCase</span>, of which - <span class="new_code">UnitTestCase</span> is one example. - Just the class names are stored for now, so that the test runner - can instantiate the class when it works its way - through your test suite. - </p> - <p> - For this to work properly the test case file should not blindly include - any other test case extensions that do not actually run tests. - This could result in extra test cases being counted during the test - run. - Hardly a major problem, but to avoid this inconvenience simply add - a <span class="new_code">SimpleTestOptions::ignore()</span> directive - somewhere in the test case file. - Also the test case file should not have been included - elsewhere or no cases will be added to this group test. - This would be a more serious error as if the test case classes are - already loaded by PHP the <span class="new_code">GroupTest::addTestFile()</span> - method will not detect them. - </p> - <p> - To display the results it is necessary only to invoke - <em>tests/all_tests.php</em> from the web server. - </p> - - <p> -<a class="target" name="mock"> -<h2>Using mock objects</h2> -</a> -</p> - <p> - Let's move further into the future. - </p> - <p> - Assume that our logging class is tested and completed. - Assume also that we are testing another class that is - required to write log messages, say a - <span class="new_code">SessionPool</span>. - We want to test a method that will probably end up looking - like this... -<pre> -<strong> -class SessionPool { - ... - function logIn($username) { - ... - $this->_log->message("User $username logged in."); - ... - } - ... -} -</strong> -</pre> - In the spirit of reuse we are using our - <span class="new_code">Log</span> class. - A conventional test case might look like this... -<pre> -<strong> -<?php -require_once('../classes/log.php'); -require_once('../classes/session_pool.php'); - -class TestOfSessionLogging extends UnitTestCase { - - function setUp() { - @unlink('/temp/test.log'); - } - - function tearDown() { - @unlink('/temp/test.log'); - } - - function testLogInIsLogged() { - $log = new Log('/temp/test.log'); - $session_pool = &new SessionPool($log); - $session_pool->logIn('fred'); - $messages = file('/temp/test.log'); - $this->assertEqual($messages[0], "User fred logged in.\n"); - } -} -?></strong> -</pre> - This test case design is not all bad, but it could be improved. - We are spending time fiddling with log files which are - not part of our test. Worse, we have created close ties - with the <span class="new_code">Log</span> class and - this test. - What if we don't use files any more, but use ths - <em>syslog</em> library instead? - Did you notice the extra carriage return in the message? - Was that added by the logger? - What if it also added a time stamp or other data? - </p> - <p> - The only part that we really want to test is that a particular - message was sent to the logger. - We reduce coupling if we can pass in a fake logging class - that simply records the message calls for testing, but - takes no action. - It would have to look exactly like our original though. - </p> - <p> - If the fake object doesn't write to a file then we save on deleting - the file before and after each test. We could save even more - test code if the fake object would kindly run the assertion for us. - <p> - </p> - Too good to be true? - Luckily we can create such an object easily... -<pre> -<?php -require_once('../classes/log.php'); -require_once('../classes/session_pool.php');<strong> -Mock::generate('Log');</strong> - -class TestOfSessionLogging extends UnitTestCase { - - function testLogInIsLogged() {<strong> - $log = &new MockLog(); - $log->expectOnce('message', array('User fred logged in.'));</strong> - $session_pool = &new SessionPool($log); - $session_pool->logIn('fred'); - } -} -?> -</pre> - The test will be triggered when the call to - <span class="new_code">message()</span> is invoked on the - <span class="new_code">MockLog</span> object. - The mock call will trigger a parameter comparison and then send the - resulting pass or fail event to the test display. - Wildcards can be included here too so as to prevent tests - becoming too specific. - </p> - <p> - If the mock reaches the end of the test case without the - method being called, the <span class="new_code">expectOnce()</span> - expectation will trigger a test failure. - In other words the mocks can detect the absence of - behaviour as well as the presence. - </p> - <p> - The mock objects in the SimpleTest suite can have arbitrary - return values set, sequences of returns, return values - selected according to the incoming arguments, sequences of - parameter expectations and limits on the number of times - a method is to be invoked. - </p> - <p> - For this test to run the mock objects library must have been - included in the test suite, say in <em>all_tests.php</em>. - </p> - - <p> -<a class="target" name="web"> -<h2>Web page testing</h2> -</a> -</p> - <p> - One of the requirements of web sites is that they produce web - pages. - If you are building a project top-down and you want to fully - integrate testing along the way then you will want a way of - automatically navigating a site and examining output for - correctness. - This is the job of a web tester. - </p> - <p> - The web testing in SimpleTest is fairly primitive, there is - no JavaScript for example. - To give an idea here is a trivial example where a home - page is fetched, from which we navigate to an "about" - page and then test some client determined content. -<pre> -<?php<strong> -require_once('simpletest/web_tester.php');</strong> -require_once('simpletest/reporter.php'); -<strong> -class TestOfAbout extends WebTestCase { - - function setUp() { - $this->get('http://test-server/index.php'); - $this->click('About'); - } - - function testSearchEngineOptimisations() { - $this->assertTitle('A long title about us for search engines'); - $this->assertPattern('/a popular keyphrase/i'); - } -}</strong> -$test = &new TestOfAbout(); -$test->run(new HtmlReporter()); -?> -</pre> - With this code as an acceptance test you can ensure that - the content always meets the specifications of both the - developers and the other project stakeholders. - </p> - <p> - <a href="http://sourceforge.net/projects/simpletest/"><img src="http://sourceforge.net/sflogo.php?group_id=76550&type=5" width="210" height="62" border="0" alt="SourceForge.net Logo"></a> - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/mock_objects_documentation.html b/tests/test_tools/simpletest/docs/en/mock_objects_documentation.html deleted file mode 100755 index eb32c619..00000000 --- a/tests/test_tools/simpletest/docs/en/mock_objects_documentation.html +++ /dev/null @@ -1,727 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>SimpleTest for PHP mock objects documentation</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<span class="chosen">Mock objects</span> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Mock objects documentation</h1> -<div class="content"> - <p> -<a class="target" name="what"> -<h2>What are mock objects?</h2> -</a> -</p> - <p> - Mock objects have two roles during a test case: actor and critic. - </p> - <p> - The actor behaviour is to simulate objects that are difficult to - set up or time consuming to set up for a test. - The classic example is a database connection. - Setting up a test database at the start of each test would slow - testing to a crawl and would require the installation of the - database engine and test data on the test machine. - If we can simulate the connection and return data of our - choosing we not only win on the pragmatics of testing, but can - also feed our code spurious data to see how it responds. - We can simulate databases being down or other extremes - without having to create a broken database for real. - In other words, we get greater control of the test environment. - </p> - <p> - If mock objects only behaved as actors they would simply be - known as server stubs. - This was originally a pattern named by Robert Binder (Testing - object-oriented systems: models, patterns, and tools, - Addison-Wesley) in 1999. - </p> - <p> - A server stub is a simulation of an object or component. - It should exactly replace a component in a system for test - or prototyping purposes, but remain lightweight. - This allows tests to run more quickly, or if the simulated - class has not been written, to run at all. - </p> - <p> - However, the mock objects not only play a part (by supplying chosen - return values on demand) they are also sensitive to the - messages sent to them (via expectations). - By setting expected parameters for a method call they act - as a guard that the calls upon them are made correctly. - If expectations are not met they save us the effort of - writing a failed test assertion by performing that duty on our - behalf. - </p> - <p> - In the case of an imaginary database connection they can - test that the query, say SQL, was correctly formed by - the object that is using the connection. - Set them up with fairly tight expectations and you will - hardly need manual assertions at all. - </p> - - <p> -<a class="target" name="creation"> -<h2>Creating mock objects</h2> -</a> -</p> - <p> - In the same way that we create server stubs, all we need is an - existing class, say a database connection that looks like this... -<pre> -<strong>class DatabaseConnection { - function DatabaseConnection() { - } - - function query() { - } - - function selectQuery() { - } -}</strong> -</pre> - The class does not need to have been implemented yet. - To create a mock version of the class we need to include the - mock object library and run the generator... -<pre> -<strong>require_once('simpletest/unit_tester.php'); -require_once('simpletest/mock_objects.php'); -require_once('database_connection.php'); - -Mock::generate('DatabaseConnection');</strong> -</pre> - This generates a clone class called - <span class="new_code">MockDatabaseConnection</span>. - We can now create instances of the new class within - our test case... -<pre> -require_once('simpletest/unit_tester.php'); -require_once('simpletest/mock_objects.php'); -require_once('database_connection.php'); - -Mock::generate('DatabaseConnection'); -<strong> -class MyTestCase extends UnitTestCase { - - function testSomething() { - $connection = &new MockDatabaseConnection(); - } -}</strong> -</pre> - Unlike the generated stubs the mock constructor needs a reference - to the test case so that it can dispatch passes and failures while - checking its expectations. - This means that mock objects can only be used within test cases. - Despite this their extra power means that stubs are hardly ever used - if mocks are available. - </p> - <p> - <a class="target" name="stub"> -<h2>Mocks as actors</h2> -</a> - </p> - <p> - The mock version of a class has all the methods of the original, - so that operations like - <span class="new_code">$connection->query()</span> are still - legal. - The return value will be <span class="new_code">null</span>, - but we can change that with... -<pre> -<strong>$connection->setReturnValue('query', 37)</strong> -</pre> - Now every time we call - <span class="new_code">$connection->query()</span> we get - the result of 37. - We can set the return value to anything, say a hash of - imaginary database results or a list of persistent objects. - Parameters are irrelevant here, we always get the same - values back each time once they have been set up this way. - That may not sound like a convincing replica of a - database connection, but for the half a dozen lines of - a test method it is usually all you need. - </p> - <p> - We can also add extra methods to the mock when generating it - and choose our own class name... -<pre> -<strong>Mock::generate('DatabaseConnection', 'MyMockDatabaseConnection', array('setOptions'));</strong> -</pre> - Here the mock will behave as if the <span class="new_code">setOptions()</span> - existed in the original class. - This is handy if a class has used the PHP <span class="new_code">overload()</span> - mechanism to add dynamic methods. - You can create a special mock to simulate this situation. - </p> - <p> - Things aren't always that simple though. - One common problem is iterators, where constantly returning - the same value could cause an endless loop in the object - being tested. - For these we need to set up sequences of values. - Let's say we have a simple iterator that looks like this... -<pre> -class Iterator { - function Iterator() { - } - - function next() { - } -} -</pre> - This is about the simplest iterator you could have. - Assuming that this iterator only returns text until it - reaches the end, when it returns false, we can simulate it - with... -<pre> -Mock::generate('Iterator'); - -class IteratorTest extends UnitTestCase() { - - function testASequence() {<strong> - $iterator = &new MockIterator(); - $iterator->setReturnValue('next', false); - $iterator->setReturnValueAt(0, 'next', 'First string'); - $iterator->setReturnValueAt(1, 'next', 'Second string');</strong> - ... - } -} -</pre> - When <span class="new_code">next()</span> is called on the - mock iterator it will first return "First string", - on the second call "Second string" will be returned - and on any other call <span class="new_code">false</span> will - be returned. - The sequenced return values take precedence over the constant - return value. - The constant one is a kind of default if you like. - </p> - <p> - Another tricky situation is an overloaded - <span class="new_code">get()</span> operation. - An example of this is an information holder with name/value pairs. - Say we have a configuration class like... -<pre> -class Configuration { - function Configuration() { - } - - function getValue($key) { - } -} -</pre> - This is a classic situation for using mock objects as - actual configuration will vary from machine to machine, - hardly helping the reliability of our tests if we use it - directly. - The problem though is that all the data comes through the - <span class="new_code">getValue()</span> method and yet - we want different results for different keys. - Luckily the mocks have a filter system... -<pre> -<strong>$config = &new MockConfiguration(); -$config->setReturnValue('getValue', 'primary', array('db_host')); -$config->setReturnValue('getValue', 'admin', array('db_user')); -$config->setReturnValue('getValue', 'secret', array('db_password'));</strong> -</pre> - The extra parameter is a list of arguments to attempt - to match. - In this case we are trying to match only one argument which - is the look up key. - Now when the mock object has the - <span class="new_code">getValue()</span> method invoked - like this... -<pre> -$config->getValue('db_user') -</pre> - ...it will return "admin". - It finds this by attempting to match the calling arguments - to its list of returns one after another until - a complete match is found. - </p> - <p> - You can set a default argument argument like so... -<pre> -<strong> -$config->setReturnValue('getValue', false, array('*'));</strong> -</pre> - This is not the same as setting the return value without - any argument requirements like this... -<pre> -<strong> -$config->setReturnValue('getValue', false);</strong> -</pre> - In the first case it will accept any single argument, - but exactly one is required. - In the second case any number of arguments will do and - it acts as a catchall after all other matches. - Note that if we add further single parameter options after - the wildcard in the first case, they will be ignored as the wildcard - will match first. - With complex parameter lists the ordering could be important - or else desired matches could be masked by earlier wildcard - ones. - Declare the most specific matches first if you are not sure. - </p> - <p> - There are times when you want a specific object to be - dished out by the mock rather than a copy. - The PHP4 copy semantics force us to use a different method - for this. - You might be simulating a container for example... -<pre> -class Thing { -} - -class Vector { - function Vector() { - } - - function get($index) { - } -} -</pre> - In this case you can set a reference into the mock's - return list... -<pre> -$thing = &new Thing();<strong> -$vector = &new MockVector(); -$vector->setReturnReference('get', $thing, array(12));</strong> -</pre> - With this arrangement you know that every time - <span class="new_code">$vector->get(12)</span> is - called it will return the same - <span class="new_code">$thing</span> each time. - This is compatible with PHP5 as well. - </p> - <p> - These three factors, timing, parameters and whether to copy, - can be combined orthogonally. - For example... -<pre> -$complex = &new MockComplexThing(); -$stuff = &new Stuff();<strong> -$complex->setReturnReferenceAt(3, 'get', $stuff, array('*', 1));</strong> -</pre> - This will return the <span class="new_code">$stuff</span> only on the third - call and only if two parameters were set the second of - which must be the integer 1. - That should cover most simple prototyping situations. - </p> - <p> - A final tricky case is one object creating another, known - as a factory pattern. - Suppose that on a successful query to our imaginary - database, a result set is returned as an iterator with - each call to <span class="new_code">next()</span> giving - one row until false. - This sounds like a simulation nightmare, but in fact it can all - be mocked using the mechanics above. - </p> - <p> - Here's how... -<pre> -Mock::generate('DatabaseConnection'); -Mock::generate('ResultIterator'); - -class DatabaseTest extends UnitTestCase { - - function testUserFinder() {<strong> - $result = &new MockResultIterator(); - $result->setReturnValue('next', false); - $result->setReturnValueAt(0, 'next', array(1, 'tom')); - $result->setReturnValueAt(1, 'next', array(3, 'dick')); - $result->setReturnValueAt(2, 'next', array(6, 'harry')); - - $connection = &new MockDatabaseConnection(); - $connection->setReturnValue('query', false); - $connection->setReturnReference( - 'query', - $result, - array('select id, name from users'));</strong> - - $finder = &new UserFinder($connection); - $this->assertIdentical( - $finder->findNames(), - array('tom', 'dick', 'harry')); - } -} -</pre> - Now only if our - <span class="new_code">$connection</span> is called with the correct - <span class="new_code">query()</span> will the - <span class="new_code">$result</span> be returned that is - itself exhausted after the third call to <span class="new_code">next()</span>. - This should be enough - information for our <span class="new_code">UserFinder</span> class, - the class actually - being tested here, to come up with goods. - A very precise test and not a real database in sight. - </p> - - <p> -<a class="target" name="expectations"> -<h2>Mocks as critics</h2> -</a> -</p> - <p> - Although the server stubs approach insulates your tests from - real world disruption, it is only half the benefit. - You can have the class under test receiving the required - messages, but is your new class sending correct ones? - Testing this can get messy without a mock objects library. - </p> - <p> - By way of example, suppose we have a - <span class="new_code">SessionPool</span> class that we - want to add logging to. - Rather than grow the original class into something more - complicated, we want to add this behaviour with a decorator (GOF). - The <span class="new_code">SessionPool</span> code currently looks - like this... -<pre> -<strong>class SessionPool { - function SessionPool() { - ... - } - - function &findSession($cookie) { - ... - } - ... -} - -class Session { - ... -}</strong> -</php> - While our logging code looks like this... -<php><strong> -class Log { - function Log() { - ... - } - - function message() { - ... - } -} - -class LoggingSessionPool { - function LoggingSessionPool(&$session_pool, &$log) { - ... - } - - function &findSession(\$cookie) { - ... - } - ... -}</strong> -</pre> - Out of all of this, the only class we want to test here - is the <span class="new_code">LoggingSessionPool</span>. - In particular we would like to check that the - <span class="new_code">findSession()</span> method is - called with the correct session ID in the cookie and that - it sent the message "Starting session $cookie" - to the logger. - </p> - <p> - Despite the fact that we are testing only a few lines of - production code, here is what we would have to do in a - conventional test case: - <ol> - <li>Create a log object.</li> - <li>Set a directory to place the log file.</li> - <li>Set the directory permissions so we can write the log.</li> - <li>Create a <span class="new_code">SessionPool</span> object.</li> - <li>Hand start a session, which probably does lot's of things.</li> - <li>Invoke <span class="new_code">findSession()</span>.</li> - <li>Read the new Session ID (hope there is an accessor!).</li> - <li>Raise a test assertion to confirm that the ID matches the cookie.</li> - <li>Read the last line of the log file.</li> - <li>Pattern match out the extra logging timestamps, etc.</li> - <li>Assert that the session message is contained in the text.</li> - </ol> - It is hardly surprising that developers hate writing tests - when they are this much drudgery. - To make things worse, every time the logging format changes or - the method of creating new sessions changes, we have to rewrite - parts of this test even though this test does not officially - test those parts of the system. - We are creating headaches for the writers of these other classes. - </p> - <p> - Instead, here is the complete test method using mock object magic... -<pre> -Mock::generate('Session'); -Mock::generate('SessionPool'); -Mock::generate('Log'); - -class LoggingSessionPoolTest extends UnitTestCase { - ... - function testFindSessionLogging() {<strong> - $session = &new MockSession(); - $pool = &new MockSessionPool(); - $pool->setReturnReference('findSession', $session); - $pool->expectOnce('findSession', array('abc')); - - $log = &new MockLog(); - $log->expectOnce('message', array('Starting session abc')); - - $logging_pool = &new LoggingSessionPool($pool, $log); - $this->assertReference($logging_pool->findSession('abc'), $session);</strong> - } -} -</pre> - We start by creating a dummy session. - We don't have to be too fussy about this as the check - for which session we want is done elsewhere. - We only need to check that it was the same one that came - from the session pool. - </p> - <p> - <span class="new_code">findSession()</span> is a factory - method the simulation of which is described <a href="#stub">above</a>. - The point of departure comes with the first - <span class="new_code">expectOnce()</span> call. - This line states that whenever - <span class="new_code">findSession()</span> is invoked on the - mock, it will test the incoming arguments. - If it receives the single argument of a string "abc" - then a test pass is sent to the unit tester, otherwise a fail is - generated. - This was the part where we checked that the right session was asked for. - The argument list follows the same format as the one for setting - return values. - You can have wildcards and sequences and the order of - evaluation is the same. - </p> - <p> - We use the same pattern to set up the mock logger. - We tell it that it should have - <span class="new_code">message()</span> invoked - once only with the argument "Starting session abc". - By testing the calling arguments, rather than the logger output, - we insulate the test from any display changes in the logger. - </p> - <p> - We start to run our tests when we create the new - <span class="new_code">LoggingSessionPool</span> and feed - it our preset mock objects. - Everything is now under our control. - </p> - <p> - This is still quite a bit of test code, but the code is very - strict. - If it still seems rather daunting there is a lot less of it - than if we tried this without mocks and this particular test, - interactions rather than output, is always more work to set - up. - More often you will be testing more complex situations without - needing this level or precision. - Also some of this can be refactored into a test case - <span class="new_code">setUp()</span> method. - </p> - <p> - Here is the full list of expectations you can set on a mock object - in <a href="http://www.lastcraft.com/simple_test.php">SimpleTest</a>... - <table> -<thead> - <tr> -<th>Expectation</th><th>Needs <span class="new_code">tally()</span></th> -</tr> - </thead> -<tbody> -<tr> - <td><span class="new_code">expect($method, $args)</span></td> - <td style="text-align: center">No</td> - </tr> - <tr> - <td><span class="new_code">expectAt($timing, $method, $args)</span></td> - <td style="text-align: center">No</td> - </tr> - <tr> - <td><span class="new_code">expectCallCount($method, $count)</span></td> - <td style="text-align: center">Yes</td> - </tr> - <tr> - <td><span class="new_code">expectMaximumCallCount($method, $count)</span></td> - <td style="text-align: center">No</td> - </tr> - <tr> - <td><span class="new_code">expectMinimumCallCount($method, $count)</span></td> - <td style="text-align: center">Yes</td> - </tr> - <tr> - <td><span class="new_code">expectNever($method)</span></td> - <td style="text-align: center">No</td> - </tr> - <tr> - <td><span class="new_code">expectOnce($method, $args)</span></td> - <td style="text-align: center">Yes</td> - </tr> - <tr> - <td><span class="new_code">expectAtLeastOnce($method, $args)</span></td> - <td style="text-align: center">Yes</td> - </tr> - </tbody> -</table> - Where the parameters are... - <dl> - <dt class="new_code">$method</dt> - <dd>The method name, as a string, to apply the condition to.</dd> - <dt class="new_code">$args</dt> - <dd> - The arguments as a list. Wildcards can be included in the same - manner as for <span class="new_code">setReturn()</span>. - This argument is optional for <span class="new_code">expectOnce()</span> - and <span class="new_code">expectAtLeastOnce()</span>. - </dd> - <dt class="new_code">$timing</dt> - <dd> - The only point in time to test the condition. - The first call starts at zero. - </dd> - <dt class="new_code">$count</dt> - <dd>The number of calls expected.</dd> - </dl> - The method <span class="new_code">expectMaximumCallCount()</span> - is slightly different in that it will only ever generate a failure. - It is silent if the limit is never reached. - </p> - <p> - Like the assertions within test cases, all of the expectations - can take a message override as an extra parameter. - Also the original failure message can be embedded in the output - as "%s". - </p> - - <p> -<a class="target" name="approaches"> -<h2>Other approaches</h2> -</a> -</p> - <p> - There are three approaches to creating mocks including the one - that SimpleTest employs. - Coding them by hand using a base class, generating them to - a file and dynamically generating them on the fly. - </p> - <p> - Mock objects generated with <a href="simple_test.html">SimpleTest</a> - are dynamic. - They are created at run time in memory, using - <span class="new_code">eval()</span>, rather than written - out to a file. - This makes the mocks easy to create, a one liner, - especially compared with hand - crafting them in a parallel class hierarchy. - The problem is that the behaviour is usually set up in the tests - themselves. - If the original objects change the mock versions - that the tests rely on can get out of sync. - This can happen with the parallel hierarchy approach as well, - but is far more quickly detected. - </p> - <p> - The solution, of course, is to add some real integration - tests. - You don't need very many and the convenience gained - from the mocks more than outweighs the small amount of - extra testing. - You cannot trust code that was only tested with mocks. - </p> - <p> - If you are still determined to build static libraries of mocks - because you want to simulate very specific behaviour, you can - achieve the same effect using the SimpleTest class generator. - In your library file, say <em>mocks/connection.php</em> for a - database connection, create a mock and inherit to override - special methods or add presets... -<pre> -<?php - require_once('simpletest/mock_objects.php'); - require_once('../classes/connection.php'); -<strong> - Mock::generate('Connection', 'BasicMockConnection'); - class MockConnection extends BasicMockConnection { - function MockConnection() { - $this->BasicMockConnection(); - $this->setReturn('query', false); - } - }</strong> -?> -</pre> - The generate call tells the class generator to create - a class called <span class="new_code">BasicMockConnection</span> - rather than the usual <span class="new_code">MockConnection</span>. - We then inherit from this to get our version of - <span class="new_code">MockConnection</span>. - By intercepting in this way we can add behaviour, here setting - the default value of <span class="new_code">query()</span> to be false. - By using the default name we make sure that the mock class - generator will not recreate a different one when invoked elsewhere in the - tests. - It never creates a class if it already exists. - As long as the above file is included first then all tests - that generated <span class="new_code">MockConnection</span> should - now be using our one instead. - If we don't get the order right and the mock library - creates one first then the class creation will simply fail. - </p> - <p> - Use this trick if you find you have a lot of common mock behaviour - or you are getting frequent integration problems at later - stages of testing. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/overview.html b/tests/test_tools/simpletest/docs/en/overview.html deleted file mode 100755 index 5d4e80e2..00000000 --- a/tests/test_tools/simpletest/docs/en/overview.html +++ /dev/null @@ -1,406 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title> - Overview and feature list for the SimpleTest PHP unit tester and web tester - </title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<span class="chosen">Overview</span> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Overview of SimpleTest</h1> -<div class="content"> - <p> -<a class="target" name="summary"> -<h2>What is SimpleTest?</h2> -</a> -</p> - <p> - 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 <span class="new_code">run()</span> - 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 - <span class="new_code">assertEqual()</span>. - 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. - </p> - <p> - A <a href="unit_test_documentation.html">test case</a> looks like this... -<pre> -<?php -class <strong>MyTestCase</strong> extends UnitTestCase { - <strong> - function testLog() { - $log = &new Log('my.log'); - $log->message('Hello'); - $this->assertTrue(file_exists('my.log')); - }</strong> -} -?> -</pre> - </p> - <p> - 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. - </p> - <p> - The simplest type of test case is the - <a href="unit_tester_documentation.html">UnitTestCase</a>. - 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. - </p> - <p> - 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 <a href="web_tester_documentation.html">WebTestCase</a> 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. - </p> - <p> - A <a href="web_tester_documentation.html">WebTestCase</a> looks like this... -<pre> -<?php -class <strong>MySiteTest</strong> extends WebTestCase { - <strong> - 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/'); - }</strong> -} -?> -</pre> - </p> - - <p> -<a class="target" name="features"> -<h2>Feature list</h2> -</a> -</p> - <p> - 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. - <table> -<thead> - <tr> -<th>Feature</th><th>Description</th><th>Release</th> -</tr> - </thead> -<tbody> -<tr> - <td>Unit test case</td> - <td>Core test case class and assertions</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Html display</td> - <td>Simplest possible display</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Autoloading of test cases</td> - <td> - Reading a file with test cases and loading them into a - group test automatically - </td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Mock objects</td> - <td> - Objects capable of simulating other objects removing - test dependencies - </td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Web test case</td> - <td>Allows link following and title tag matching</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Partial mocks</td> - <td> - Mocking parts of a class for testing less than a class - or for complex simulations - </td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Web cookie handling</td> - <td>Correct handling of cookies when fetching pages</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Following redirects</td> - <td>Page fetching automatically follows 300 redirects</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Form parsing</td> - <td>Ability to submit simple forms and read default form values</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Command line interface</td> - <td>Test display without the need of a web browser</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Exposure of expectation classes</td> - <td>Can create precise tests with mocks as well as test cases</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>XML output and parsing</td> - <td> - Allows multi host testing and the integration of acceptance - testing extensions - </td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Browser component</td> - <td> - Exposure of lower level web browser interface for more - detailed test cases - </td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>HTTP authentication</td> - <td> - Fetching protected web pages with basic authentication - only - </td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>SSL support</td> - <td>Can connect to https: pages</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Proxy support</td> - <td>Can connect via. common proxies</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>Frames support</td> - <td>Handling of frames in web test cases</td> - <td style="color: green;">1.0</td> - </tr> - <tr> - <td>File upload testing</td> - <td>Can simulate the input type file tag</td> - <td style="color: green;">1.0.1</td> - </tr> - <tr> - <td>Mocking interfaces</td> - <td> - Can generate mock objects to interfaces as well as classes - and class interfaces are carried for type hints - </td> - <td style="color: green;">1.0.1</td> - </tr> - <tr> - <td>Reporting machinery enhancements</td> - <td>Improved message passing for better cooperation with IDEs</td> - <td style="color: red;">1.1</td> - </tr> - <tr> - <td>Localisation</td> - <td>Messages abstracted and code generated from XML</td> - <td style="color: red;">1.1</td> - </tr> - <tr> - <td>Testing exceptions</td> - <td>Similar to testing PHP errors</td> - <td style="color: red;">1.1</td> - </tr> - <tr> - <td>IFrame support</td> - <td>Reads IFrame content that can be refreshed</td> - <td style="color: red;">1.1</td> - </tr> - <tr> - <td>Improved mock interface</td> - <td>More compact way of expressing mocks</td> - <td style="color: red;">2.0</td> - </tr> - <tr> - <td>HTML table assertions</td> - <td>Can match table elements to numerical assertions</td> - <td style="color: red;">2.0</td> - </tr> - <tr> - <td>XPath searching of HTML elements</td> - <td>More flexible content matching</td> - <td style="color: red;">2.0</td> - </tr> - <tr> - <td>Alternate HTML parsers</td> - <td>Can detect compiled parsers for performance improvements</td> - <td style="color: red;">2.0</td> - </tr> - <tr> - <td>Javascript suport</td> - <td>Use of PECL module to add Javascript</td> - <td style="color: red;">3.0</td> - </tr> - </tbody> -</table> - PHP5 migraton will start straight after the version 1.0.1 series, - whereupon PHP4 will no longer be supported. - SimpleTest is currently compatible with PHP5, but will not - make use of all of the new features until version 2. - </p> - - <p> -<a class="target" name="resources"> -<h2>Web resources for testing</h2> -</a> -</p> - <p> - 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 - <a href="http://www.extremeprogramming.org/">Extreme Programming</a>. - This is one of the - <a href="http://www.agilealliance.com/articles/index">Agile Methodologies</a> - which combine various practices to "flatten the cost curve" of software development. - More extreme still is <a href="http://www.testdriven.com/modules/news/">Test Driven Development</a>, - 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 - <a href="http://www.therationaledge.com/content/dec_01/f_spiritOfTheRUP_pk.html">RUP</a> approach. - I haven't tried it, but even I can see that you will need test tools (see figure 9). - </p> - <p> - Most unit testers clone <a href="http://www.junit.org/">JUnit</a> to some degree, - as far as the interface at least. There is a wealth of information on the - JUnit site including the - <a href="http://junit.sourceforge.net/doc/faq/faq.htm">FAQ</a> - which contains plenty of general advice on testing. - Once you get bitten by the bug you will certainly appreciate the phrase - <a href="http://junit.sourceforge.net/doc/testinfected/testing.htm">test infected</a> - coined by Eric Gamma. - If you are still reviewing which unit tester to use the main choices - are <a href="http://phpunit.sourceforge.net/">PHPUnit</a> - and <a href="http://pear.php.net/manual/en/package.php.phpunit.php">Pear PHP::PHPUnit</a>. - They currently lack a lot of features found in - <a href="http://www.lastcraft.com/simple_test.php">SimpleTest</a>, but the PEAR - version at least has been upgraded for PHP5 and is recommended if you are porting - existing <a href="http://www.junit.org/">JUnit</a> test cases. - </p> - <p> - 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 <a href="http://www.sidewize.com/company/mockobjects.pdf">original mock objects paper</a> - 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 - <a href="http://xpdeveloper.com/cgi-bin/oldwiki.cgi?MockObjects">Extreme Tuesday</a> - or <a href="http://www.mockobjects.com/MocksObjectsPaper.html">www.mockobjects.com</a> - or <a href="http://c2.com/cgi/wiki?MockObject">the original C2 Wiki</a>. - Injecting mocks into a class is the main area of debate for which this - <a href="http://www-106.ibm.com/developerworks/java/library/j-mocktest.html">paper on IBM</a> - makes a good starting point. - </p> - <p> - There are plenty of web testing tools, but the scriptable ones - are mostly are written in Java and - tutorials and advice are rather thin on the ground. - The only hope is to look at the documentation for - <a href="http://httpunit.sourceforge.net/">HTTPUnit</a>, - <a href="http://htmlunit.sourceforge.net/">HTMLUnit</a> - or <a href="http://jwebunit.sourceforge.net/">JWebUnit</a> and hope for clues. - There are some XML driven test frameworks, but again most - require Java to run. - </p> - <p> - A new generation of tools that run directly in the web browser - are now available. - These include - <a href="http://www.openqa.org/selenium/">Selenium</a> and - <a href="http://wtr.rubyforge.org/">Watir</a>. - As SimpleTest does not support JavaScript you would probably - have to look at these tools anyway if you have highly dynamic - pages. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/partial_mocks_documentation.html b/tests/test_tools/simpletest/docs/en/partial_mocks_documentation.html deleted file mode 100755 index 6d7b6243..00000000 --- a/tests/test_tools/simpletest/docs/en/partial_mocks_documentation.html +++ /dev/null @@ -1,423 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>SimpleTest for PHP partial mocks documentation</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<span class="chosen">Partial mocks</span> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Partial mock objects documentation</h1> -<div class="content"> - - <p> - A partial mock is simply a pattern to alleviate a specific problem - in testing with mock objects, - that of getting mock objects into tight corners. - It's quite a limited tool and possibly not even a good idea. - It is included with SimpleTest because I have found it useful - on more than one occasion and has saved a lot of work at that point. - </p> - - <p> -<a class="target" name="inject"> -<h2>The mock injection problem</h2> -</a> -</p> - <p> - When one object uses another it is very simple to just pass a mock - version in already set up with its expectations. - Things are rather tricker if one object creates another and the - creator is the one you want to test. - This means that the created object should be mocked, but we can - hardly tell our class under test to create a mock instead. - The tested class doesn't even know it is running inside a test - after all. - </p> - <p> - For example, suppose we are building a telnet client and it - needs to create a network socket to pass its messages. - The connection method might look something like... -<pre> -<strong><?php - require_once('socket.php'); - - class Telnet { - ... - function &connect($ip, $port, $username, $password) { - $socket = &new Socket($ip, $port); - $socket->read( ... ); - ... - } - } -?></strong> -</pre> - We would really like to have a mock object version of the socket - here, what can we do? - </p> - <p> - The first solution is to pass the socket in as a parameter, - forcing the creation up a level. - Having the client handle this is actually a very good approach - if you can manage it and should lead to factoring the creation from - the doing. - In fact, this is one way in which testing with mock objects actually - forces you to code more tightly focused solutions. - They improve your programming. - </p> - <p> - Here this would be... -<pre> -<?php - require_once('socket.php'); - - class Telnet { - ... - <strong>function &connect(&$socket, $username, $password) { - $socket->read( ... ); - ... - }</strong> - } -?> -</pre> - This means that the test code is typical for a test involving - mock objects. -<pre> -class TelnetTest extends UnitTestCase { - ... - function testConnection() {<strong> - $socket = &new MockSocket($this); - ... - $telnet = &new Telnet(); - $telnet->connect($socket, 'Me', 'Secret'); - ...</strong> - } -} -</pre> - It is pretty obvious though that one level is all you can go. - You would hardly want your top level application creating - every low level file, socket and database connection ever - needed. - It wouldn't know the constructor parameters anyway. - </p> - <p> - The next simplest compromise is to have the created object passed - in as an optional parameter... -<pre> -<?php - require_once('socket.php'); - - class Telnet { - ...<strong> - function &connect($ip, $port, $username, $password, $socket = false) { - if (!$socket) { - $socket = &new Socket($ip, $port); - } - $socket->read( ... );</strong> - ... - return $socket; - } - } -?> -</pre> - For a quick solution this is usually good enough. - The test now looks almost the same as if the parameter - was formally passed... -<pre> -class TelnetTest extends UnitTestCase { - ... - function testConnection() {<strong> - $socket = &new MockSocket($this); - ... - $telnet = &new Telnet(); - $telnet->connect('127.0.0.1', 21, 'Me', 'Secret', &$socket); - ...</strong> - } -} -</pre> - The problem with this approach is its untidiness. - There is test code in the main class and parameters passed - in the test case that are never used. - This is a quick and dirty approach, but nevertheless effective - in most situations. - </p> - <p> - The next method is to pass in a factory object to do the creation... -<pre> -<?php - require_once('socket.php'); - - class Telnet {<strong> - function Telnet(&$network) { - $this->_network = &$network; - }</strong> - ... - function &connect($ip, $port, $username, $password) {<strong> - $socket = &$this->_network->createSocket($ip, $port); - $socket->read( ... );</strong> - ... - return $socket; - } - } -?> -</pre> - This is probably the most highly factored answer as creation - is now moved into a small specialist class. - The networking factory can now be tested separately, but mocked - easily when we are testing the telnet class... -<pre> -class TelnetTest extends UnitTestCase { - ... - function testConnection() {<strong> - $socket = &new MockSocket($this); - ... - $network = &new MockNetwork($this); - $network->setReturnReference('createSocket', $socket); - $telnet = &new Telnet($network); - $telnet->connect('127.0.0.1', 21, 'Me', 'Secret'); - ...</strong> - } -} -</pre> - The downside is that we are adding a lot more classes to the - library. - Also we are passing a lot of factories around which will - make the code a little less intuitive. - The most flexible solution, but the most complex. - </p> - <p> - Is there a middle ground? - </p> - - <p> -<a class="target" name="creation"> -<h2>Protected factory method</h2> -</a> -</p> - <p> - There is a way we can circumvent the problem without creating - any new application classes, but it involves creating a subclass - when we do the actual testing. - Firstly we move the socket creation into its own method... -<pre> -<?php - require_once('socket.php'); - - class Telnet { - ... - function &connect($ip, $port, $username, $password) {<strong> - $socket = &$this->_createSocket($ip, $port);</strong> - $socket->read( ... ); - ... - }<strong> - - function &_createSocket($ip, $port) { - return new Socket($ip, $port); - }</strong> - } -?> -</pre> - This is the only change we make to the application code. - </p> - <p> - For the test case we have to create a subclass so that - we can intercept the socket creation... -<pre> -<strong>class TelnetTestVersion extends Telnet { - var $_mock; - - function TelnetTestVersion(&$mock) { - $this->_mock = &$mock; - $this->Telnet(); - } - - function &_createSocket() { - return $this->_mock; - } -}</strong> -</pre> - Here I have passed the mock in the constructor, but a - setter would have done just as well. - Note that the mock was set into the object variable - before the constructor was chained. - This is necessary in case the constructor calls - <span class="new_code">connect()</span>. - Otherwise it could get a null value from - <span class="new_code">_createSocket()</span>. - </p> - <p> - After the completion of all of this extra work the - actual test case is fairly easy. - We just test our new class instead... -<pre> -class TelnetTest extends UnitTestCase { - ... - function testConnection() {<strong> - $socket = &new MockSocket($this); - ... - $telnet = &new TelnetTestVersion($socket); - $telnet->connect('127.0.0.1', 21, 'Me', 'Secret'); - ...</strong> - } -} -</pre> - The new class is very simple of course. - It just sets up a return value, rather like a mock. - It would be nice if it also checked the incoming parameters - as well. - Just like a mock. - It seems we are likely to do this often, can - we automate the subclass creation? - </p> - - <p> -<a class="target" name="partial"> -<h2>A partial mock</h2> -</a> -</p> - <p> - Of course the answer is "yes" or I would have stopped writing - this by now! - The previous test case was a lot of work, but we can - generate the subclass using a similar approach to the mock objects. - </p> - <p> - Here is the partial mock version of the test... -<pre> -<strong>Mock::generatePartial( - 'Telnet', - 'TelnetTestVersion', - array('_createSocket'));</strong> - -class TelnetTest extends UnitTestCase { - ... - function testConnection() {<strong> - $socket = &new MockSocket($this); - ... - $telnet = &new TelnetTestVersion($this); - $telnet->setReturnReference('_createSocket', $socket); - $telnet->Telnet(); - $telnet->connect('127.0.0.1', 21, 'Me', 'Secret'); - ...</strong> - } -} -</pre> - The partial mock is a subclass of the original with - selected methods "knocked out" with test - versions. - The <span class="new_code">generatePartial()</span> call - takes three parameters: the class to be subclassed, - the new test class name and a list of methods to mock. - </p> - <p> - Instantiating the resulting objects is slightly tricky. - The only constructor parameter of a partial mock is - the unit tester reference. - As with the normal mock objects this is needed for sending - test results in response to checked expectations. - </p> - <p> - The original constructor is not run yet. - This is necessary in case the constructor is going to - make use of the as yet unset mocked methods. - We set any return values at this point and then run the - constructor with its normal parameters. - This three step construction of "new", followed - by setting up the methods, followed by running the constructor - proper is what distinguishes the partial mock code. - </p> - <p> - Apart from construction, all of the mocked methods have - the same features as mock objects and all of the unmocked - methods behave as before. - We can set expectations very easily... -<pre> -class TelnetTest extends UnitTestCase { - ... - function testConnection() { - $socket = &new MockSocket($this); - ... - $telnet = &new TelnetTestVersion($this); - $telnet->setReturnReference('_createSocket', $socket);<strong> - $telnet->expectOnce('_createSocket', array('127.0.0.1', 21));</strong> - $telnet->Telnet(); - $telnet->connect('127.0.0.1', 21, 'Me', 'Secret'); - ...<strong> - $telnet->tally();</strong> - } -} -</pre> - </p> - - <p> -<a class="target" name="less"> -<h2>Testing less than a class</h2> -</a> -</p> - <p> - The mocked out methods don't have to be factory methods, - they could be any sort of method. - In this way partial mocks allow us to take control of any part of - a class except the constructor. - We could even go as far as to mock every method - except one we actually want to test. - </p> - <p> - This last situation is all rather hypothetical, as I haven't - tried it. - I am open to the possibility, but a little worried that - forcing object granularity may be better for the code quality. - I personally use partial mocks as a way of overriding creation - or for occasional testing of the TemplateMethod pattern. - </p> - <p> - It's all going to come down to the coding standards of your - project to decide which mechanism you use. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/reporter_documentation.html b/tests/test_tools/simpletest/docs/en/reporter_documentation.html deleted file mode 100755 index ead61175..00000000 --- a/tests/test_tools/simpletest/docs/en/reporter_documentation.html +++ /dev/null @@ -1,512 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>SimpleTest for PHP test runner and display documentation</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<span class="chosen">Reporting</span> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Test reporter documentation</h1> -<div class="content"> - - <p> - SimpleTest pretty much follows the MVC pattern - (Model-View-Controller). - The reporter classes are the view and the model is your - test cases and their hiearchy. - The controller is mostly hidden from the user of - SimpleTest unless you want to change how the test cases - are actually run, in which case it is possible to - override the runner objects from within the test case. - As usual with MVC, the controller is mostly undefined - and there are other places to control the test run. - </p> - - <p> -<a class="target" name="html"> -<h2>Reporting results in HTML</h2> -</a> -</p> - <p> - The default test display is minimal in the extreme. - It reports success and failure with the conventional red and - green bars and shows a breadcrumb trail of test groups - for every failed assertion. - Here's a fail... - <div class="demo"> - <h1>File test</h1> - <span class="fail">Fail</span>: createnewfile->True assertion failed.<br> - <div style="padding: 8px; margin-top: 1em; background-color: red; color: white;">1/1 test cases complete. - <strong>0</strong> passes, <strong>1</strong> fails and <strong>0</strong> exceptions.</div> - </div> - And here all tests passed... - <div class="demo"> - <h1>File test</h1> - <div style="padding: 8px; margin-top: 1em; background-color: green; color: white;">1/1 test cases complete. - <strong>1</strong> passes, <strong>0</strong> fails and <strong>0</strong> exceptions.</div> - </div> - The good news is that there are several points in the display - hiearchy for subclassing. - </p> - <p> - For web page based displays there is the - <span class="new_code">HtmlReporter</span> class with the following - signature... -<pre> -class HtmlReporter extends SimpleReporter { - public HtmlReporter($encoding) { ... } - public makeDry(boolean $is_dry) { ... } - public void paintHeader(string $test_name) { ... } - public void sendNoCacheHeaders() { ... } - public void paintFooter(string $test_name) { ... } - public void paintGroupStart(string $test_name, integer $size) { ... } - public void paintGroupEnd(string $test_name) { ... } - public void paintCaseStart(string $test_name) { ... } - public void paintCaseEnd(string $test_name) { ... } - public void paintMethodStart(string $test_name) { ... } - public void paintMethodEnd(string $test_name) { ... } - public void paintFail(string $message) { ... } - public void paintPass(string $message) { ... } - public void paintError(string $message) { ... } - public void paintException(string $message) { ... } - public void paintMessage(string $message) { ... } - public void paintFormattedMessage(string $message) { ... } - protected string _getCss() { ... } - public array getTestList() { ... } - public integer getPassCount() { ... } - public integer getFailCount() { ... } - public integer getExceptionCount() { ... } - public integer getTestCaseCount() { ... } - public integer getTestCaseProgress() { ... } -} -</pre> - Here is what some of these methods mean. First the display methods - that you will probably want to override... - <ul class="api"> - <li> - <span class="new_code">HtmlReporter(string $encoding)</span> -<br> - is the constructor. - Note that the unit test sets up the link to the display - rather than the other way around. - The display is a mostly passive receiver of test events. - This allows easy adaption of the display for other test - systems beside unit tests, such as monitoring servers. - The encoding is the character encoding you wish to - display the test output in. - In order to correctly render debug output when - using the web tester, this should match the encoding - of the site you are trying to test. - The available character set strings are described in - the PHP <a href="http://www.php.net/manual/en/function.htmlentities.php">html_entities()</a> - function. - </li> - <li> - <span class="new_code">void paintHeader(string $test_name)</span> -<br> - is called once at the very start of the test when the first - start event arrives. - The first start event is usually delivered by the top level group - test and so this is where <span class="new_code">$test_name</span> - comes from. - It paints the page titles, CSS, body tag, etc. - It returns nothing (<span class="new_code">void</span>). - </li> - <li> - <span class="new_code">void paintFooter(string $test_name)</span> -<br> - Called at the very end of the test to close any tags opened - by the page header. - By default it also displays the red/green bar and the final - count of results. - Actually the end of the test happens when a test end event - comes in with the same name as the one that started it all - at the same level. - The tests nest you see. - Closing the last test finishes the display. - </li> - <li> - <span class="new_code">void paintMethodStart(string $test_name)</span> -<br> - is called at the start of each test method. - The name normally comes from method name. - The other test start events behave the same way except - that the group test one tells the reporter how large - it is in number of held test cases. - This is so that the reporter can display a progress bar - as the runner churns through the test cases. - </li> - <li> - <span class="new_code">void paintMethodEnd(string $test_name)</span> -<br> - backs out of the test started with the same name. - </li> - <li> - <span class="new_code">void paintFail(string $message)</span> -<br> - paints a failure. - By default it just displays the word fail, a breadcrumbs trail - showing the current test nesting and the message issued by - the assertion. - </li> - <li> - <span class="new_code">void paintPass(string $message)</span> -<br> - by default does nothing. - </li> - <li> - <span class="new_code">string _getCss()</span> -<br> - Returns the CSS styles as a string for the page header - method. - Additional styles have to be appended here if you are - not overriding the page header. - You will want to use this method in an overriden page header - if you want to include the original CSS. - </li> - </ul> - There are also some accessors to get information on the current - state of the test suite. - Use these to enrich the display... - <ul class="api"> - <li> - <span class="new_code">array getTestList()</span> -<br> - is the first convenience method for subclasses. - Lists the current nesting of the tests as a list - of test names. - The first, most deeply nested test, is first in the - list and the current test method will be last. - </li> - <li> - <span class="new_code">integer getPassCount()</span> -<br> - returns the number of passes chalked up so far. - Needed for the display at the end. - </li> - <li> - <span class="new_code">integer getFailCount()</span> -<br> - is likewise the number of fails so far. - </li> - <li> - <span class="new_code">integer getExceptionCount()</span> -<br> - is likewise the number of errors so far. - </li> - <li> - <span class="new_code">integer getTestCaseCount()</span> -<br> - is the total number of test cases in the test run. - This includes the grouping tests themselves. - </li> - <li> - <span class="new_code">integer getTestCaseProgress()</span> -<br> - is the number of test cases completed so far. - </li> - </ul> - One simple modification is to get the HtmlReporter to display - the passes as well as the failures and errors... -<pre> -<strong>class ShowPasses extends HtmlReporter { - - function paintPass($message) { - parent::paintPass($message); - print "&<span class=\"pass\">Pass</span>: "; - $breadcrumb = $this->getTestList(); - array_shift($breadcrumb); - print implode("-&gt;", $breadcrumb); - print "-&gt;$message<br />\n"; - } - - function _getCss() { - return parent::_getCss() . ' .pass { color: green; }'; - } -}</strong> -</pre> - </p> - <p> - One method that was glossed over was the <span class="new_code">makeDry()</span> - method. - If you run this method, with no parameters, on the reporter - before the test suite is run no actual test methods - will be called. - You will still get the events of entering and leaving the - test methods and test cases, but no passes or failures etc, - because the test code will not actually be executed. - </p> - <p> - The reason for this is to allow for more sophistcated - GUI displays that allow the selection of individual test - cases. - In order to build a list of possible tests they need a - report on the test structure for drawing, say a tree view - of the test suite. - With a reporter set to dry run that just sends drawing events - this is easily accomplished. - </p> - - <p> -<a class="target" name="other"> -<h2>Extending the reporter</h2> -</a> -</p> - <p> - Rather than simply modifying the existing display, you might want to - produce a whole new HTML look, or even generate text or XML. - Rather than override every method in - <span class="new_code">HtmlReporter</span> we can take one - step up the class hiearchy to <span class="new_code">SimpleReporter</span> - in the <em>simple_test.php</em> source file. - </p> - <p> - A do nothing display, a blank canvas for your own creation, would - be... -<pre> -<strong>require_once('simpletest/simple_test.php');</strong> - -class MyDisplay extends SimpleReporter {<strong> - </strong> - function paintHeader($test_name) { - } - - function paintFooter($test_name) { - } - - function paintStart($test_name, $size) {<strong> - parent::paintStart($test_name, $size);</strong> - } - - function paintEnd($test_name, $size) {<strong> - parent::paintEnd($test_name, $size);</strong> - } - - function paintPass($message) {<strong> - parent::paintPass($message);</strong> - } - - function paintFail($message) {<strong> - parent::paintFail($message);</strong> - } -} -</pre> - No output would come from this class until you add it. - </p> - - <p> -<a class="target" name="cli"> -<h2>The command line reporter</h2> -</a> -</p> - <p> - SimpleTest also ships with a minimal command line reporter. - The interface mimics JUnit to some extent, but paints the - failure messages as they arrive. - To use the command line reporter simply substitute it - for the HTML version... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php'); - - $test = &new GroupTest('File test'); - $test->addTestFile('tests/file_test.php'); - $test->run(<strong>new TextReporter()</strong>); -?> -</pre> - Then invoke the test suite from the command line... -<pre class="shell"> -php file_test.php -</pre> - You will need the command line version of PHP installed - of course. - A passing test suite looks like this... -<pre class="shell"> -File test -OK -Test cases run: 1/1, Failures: 0, Exceptions: 0 -</pre> - A failure triggers a display like this... -<pre class="shell"> -File test -1) True assertion failed. - in createnewfile -FAILURES!!! -Test cases run: 1/1, Failures: 1, Exceptions: 0 -</pre> - </p> - <p> - One of the main reasons for using a command line driven - test suite is of using the tester as part of some automated - process. - To function properly in shell scripts the test script should - return a non-zero exit code on failure. - If a test suite fails the value <span class="new_code">false</span> - is returned from the <span class="new_code">SimpleTest::run()</span> - method. - We can use that result to exit the script with the desired return - code... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php'); - - $test = &new GroupTest('File test'); - $test->addTestFile('tests/file_test.php'); - <strong>exit ($test->run(new TextReporter()) ? 0 : 1);</strong> -?> -</pre> - Of course we don't really want to create two test scripts, - a command line one and a web browser one, for each test suite. - The command line reporter includes a method to sniff out the - run time environment... -<pre> -<?php - require_once('simpletest/unit_tester.php'); - require_once('simpletest/reporter.php'); - - $test = &new GroupTest('File test'); - $test->addTestFile('tests/file_test.php'); - <strong>if (TextReporter::inCli()) {</strong> - exit ($test->run(new TextReporter()) ? 0 : 1); - <strong>}</strong> - $test->run(new HtmlReporter()); -?> -</pre> - This is the form used within SimpleTest itself. - </p> - - <p> -<a class="target" name="xml"> -<h2>Remote testing</h2> -</a> -</p> - <p> - SimpleTest ships with an <span class="new_code">XmlReporter</span> class - used for internal communication. - When run the output looks like... -<pre class="shell"> -<?xml version="1.0"?> -<run> - <group size="4"> - <name>Remote tests</name> - <group size="4"> - <name>Visual test with 48 passes, 48 fails and 4 exceptions</name> - <case> - <name>testofunittestcaseoutput</name> - <test> - <name>testofresults</name> - <pass>This assertion passed</pass> - <fail>This assertion failed</fail> - </test> - <test> - ... - </test> - </case> - </group> - </group> -</run> -</pre> - You can make use of this format with the parser - supplied as part of SimpleTest itself. - This is called <span class="new_code">SimpleTestXmlParser</span> and - resides in <em>xml.php</em> within the SimpleTest package... -<pre> -<?php - require_once('simpletest/xml.php'); - - ... - $parser = &new SimpleTestXmlParser(new HtmlReporter()); - $parser->parse($test_output); -?> -</pre> - The <span class="new_code">$test_output</span> should be the XML format - from the XML reporter, and could come from say a command - line run of a test case. - The parser sends events to the reporter just like any - other test run. - There are some odd occasions where this is actually useful. - </p> - <p> - A problem with large test suites is thet they can exhaust - the default 8Mb memory limit on a PHP process. - By having the test groups output in XML and run in - separate processes, the output can be reparsed to - aggregate the results into a much smaller footprint top level - test. - </p> - <p> - Because the XML output can come from anywhere, this opens - up the possibility of aggregating test runs from remote - servers. - A test case already exists to do this within the SimpleTest - framework, but it is currently experimental... -<pre> -<?php - <strong>require_once('../remote.php');</strong> - require_once('../reporter.php'); - - $test_url = ...; - $dry_url = ...; - - $test = &new GroupTest('Remote tests'); - $test->addTestCase(<strong>new RemoteTestCase($test_url, $dry_url)</strong>); - $test->run(new HtmlReporter()); -?> -</pre> - The <span class="new_code">RemoteTestCase</span> takes the actual location - of the test runner, basically a web page in XML format. - It also takes the URL of a reporter set to do a dry run. - This is so that progress can be reported upward correctly. - The <span class="new_code">RemoteTestCase</span> can be added to test suites - just like any other group test. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/server_stubs_documentation.html b/tests/test_tools/simpletest/docs/en/server_stubs_documentation.html deleted file mode 100755 index 4b18bb0b..00000000 --- a/tests/test_tools/simpletest/docs/en/server_stubs_documentation.html +++ /dev/null @@ -1,388 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>SimpleTest for PHP server stubs documentation</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<span class="chosen">Server stubs</span> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Server stubs documentation</h1> -<div class="content"> - <p> -<a class="target" name="what"> -<h2>What are server stubs?</h2> -</a> -</p> - <p> - This was originally a pattern named by Robert Binder (Testing - object-oriented systems: models, patterns, and tools, - Addison-Wesley) in 1999. - A server stub is a simulation of an object or component. - It should exactly replace a component in a system for test - or prototyping purposes, but remain lightweight. - This allows tests to run more quickly, or if the simulated - class has not been written, to run at all. - </p> - - <p> -<a class="target" name="creation"> -<h2>Creating server stubs</h2> -</a> -</p> - <p> - All we need is an existing class, say a database connection - that looks like this... -<pre> -<strong>class DatabaseConnection { - function DatabaseConnection() { - } - - function query() { - } - - function selectQuery() { - } -}</strong> -</pre> - The class does not need to have been implemented yet. - To create a stub version of the class we need to include the - server stub library and run the generator... -<pre> -<strong>require_once('simpletest/mock_objects.php'); -require_once('database_connection.php'); -Stub::generate('DatabaseConnection');</strong> -</pre> - This generates a clone class called - <span class="new_code">StubDatabaseConnection</span>. - We can now create instances of the new class within - our prototype script... -<pre> -require_once('simpletest/mock_objects.php'); -require_once('database_connection.php'); -Stub::generate('DatabaseConnection'); -<strong> -$connection = new StubDatabaseConnection(); -</strong> -</pre> - The stub version of a class has all the methods of the original - so that operations like - <span class="new_code">$connection->query()</span> are still - legal. - The return value will be <span class="new_code">null</span>, - but we can change that with... -<pre> -<strong>$connection->setReturnValue('query', 37)</strong> -</pre> - Now every time we call - <span class="new_code">$connection->query()</span> we get - the result of 37. - We can set the return value to anything, say a hash of - imaginary database results or a list of persistent objects. - Parameters are irrelevant here, we always get the same - values back each time once they have been set up this way. - That may not sound like a convincing replica of a - database connection, but for the half a dozen lines of - a test method it is usually all you need. - </p> - - <p> -<a class="target" name="patterns"> -<h2>Simulation patterns</h2> -</a> -</p> - <p> - Things aren't always that simple though. - One common problem is iterators, where constantly returning - the same value could cause an endless loop in the object - being tested. - For these we need to set up sequences of values. - Let's say we have a simple iterator that looks like this... -<pre> -class Iterator { - function Iterator() { - } - - function next() { - } -} -</pre> - This is about the simplest iterator you could have. - Assuming that this iterator only returns text until it - reaches the end, when it returns false, we can simulate it - with... -<pre> -<strong>Stub::generate('Iterator'); - -$iterator = new StubIterator(); -$iterator->setReturnValue('next', false); -$iterator->setReturnValueAt(0, 'next', 'First string'); -$iterator->setReturnValueAt(1, 'next', 'Second string');</strong> -</pre> - When <span class="new_code">next()</span> is called on the - stub iterator it will first return "First string", - on the second call "Second string" will be returned - and on any other call <span class="new_code">false</span> will - be returned. - The sequenced return values take precedence over the constant - return value. - The constant one is a kind of default if you like. - </p> - <p> - Another tricky situation is an overloaded - <span class="new_code">get()</span> operation. - An example of this is an information holder with name/value pairs. - Say we have a configuration class like... -<pre> -class Configuration { - function Configuration() { - } - - function getValue($key) { - } -} -</pre> - This is a classic situation for using stub objects as - actual configuration will vary from machine to machine, - hardly helping the reliability of our tests if we use it - directly. - The problem though is that all the data comes through the - <span class="new_code">getValue()</span> method and yet - we want different results for different keys. - Luckily the stubs have a filter system... -<pre> -<strong>Stub::generate('Configuration'); - -$config = &new StubConfiguration(); -$config->setReturnValue('getValue', 'primary', array('db_host')); -$config->setReturnValue('getValue', 'admin', array('db_user')); -$config->setReturnValue('getValue', 'secret', array('db_password'));</strong> -</pre> - The extra parameter is a list of arguments to attempt - to match. - In this case we are trying to match only one argument which - is the look up key. - Now when the server stub has the - <span class="new_code">getValue()</span> method invoked - like this... -<pre> -$config->getValue('db_user'); -</pre> - ...it will return "admin". - It finds this by attempting to match the calling arguments - to its list of returns one after another until - a complete match is found. - </p> - <p> - You can set a default argument argument like so... -<pre> -<strong> -$config->setReturnValue('getValue', false, array('*'));</strong> -</pre> - This is not the same as setting the return value without - any argument requirements like this... -<pre> -<strong> -$config->setReturnValue('getValue', false);</strong> -</pre> - In the first case it will accept any single argument, - but exactly one is required. - In the second case any number of arguments will do and - it acts as a catchall after all other matches. - Note that if we add further single parameter options after - the wildcard in the first case, they will be ignored as the wildcard - will match first. - With complex parameter lists the ordering could be important - or else desired matches could be masked by earlier wildcard - ones. - Declare the most specific matches first if you are not sure. - </p> - <p> - There are times when you want a specific object to be - dished out by the stub rather than just a copy. - The PHP copy semantics force us to use a different method - for this. - You might be simulating a container for example... -<pre> -class Thing { -} - -class Vector { - function Vector() { - } - - function get($index) { - } -} -</pre> - In this case you can set a reference into the stub's - return list... -<pre> -Stub::generate('Vector'); - -$thing = new Thing();<strong> -$vector = &new StubVector(); -$vector->setReturnReference('get', $thing, array(12));</strong> -</pre> - With this arrangement you know that every time - <span class="new_code">$vector->get(12)</span> is - called it will return the same - <span class="new_code">$thing</span> each time. - </p> - <p> - These three factors, timing, parameters and whether to copy, - can be combined orthogonally. - For example... -<pre> -$complex = &new StubComplexThing(); -$stuff = new Stuff();<strong> -$complex->setReturnReferenceAt(3, 'get', $stuff, array('*', 1));</strong> -</pre> - This will return the <span class="new_code">$stuff</span> only on the third - call and only if two parameters were set the second of - which must be the integer 1. - That should cover most simple prototyping situations. - </p> - <p> - A final tricky case is one object creating another, known - as a factory pattern. - Suppose that on a successful query to our imaginary - database, a result set is returned as an iterator with - each call to <span class="new_code">next()</span> giving - one row until false. - This sounds like a simulation nightmare, but in fact it can all - be stubbed using the mechanics above. - </p> - <p> - Here's how... -<pre> -Stub::generate('DatabaseConnection'); -Stub::generate('ResultIterator'); - -class DatabaseTest extends UnitTestCase { - - function testUserFinder() {<strong> - $result = &new StubResultIterator(); - $result->setReturnValue('next', false); - $result->setReturnValueAt(0, 'next', array(1, 'tom')); - $result->setReturnValueAt(1, 'next', array(3, 'dick')); - $result->setReturnValueAt(2, 'next', array(6, 'harry')); - - $connection = &new StubDatabaseConnection(); - $connection->setReturnValue('query', false); - $connection->setReturnReference( - 'query', - $result, - array('select id, name from users'));</strong> - - $finder = &new UserFinder($connection); - $this->assertIdentical( - $finder->findNames(), - array('tom', 'dick', 'harry')); - } -} -</pre> - Now only if our - <span class="new_code">$connection</span> is called with the correct - <span class="new_code">query()</span> will the - <span class="new_code">$result</span> be returned that is - itself exhausted after the third call to <span class="new_code">next()</span>. - This should be enough - information for our <span class="new_code">UserFinder</span> class, - the class actually - being tested here, to come up with goods. - A very precise test and not a real database in sight. - </p> - - <p> -<a class="target" name="options"> -<h2>Stub creation options</h2> -</a> -</p> - <p> - There are some additional options when creating stubs. - At the generation stage we can change the class name... -<pre> -<strong>Stub::generate('Iterator', 'MyStubIterator'); -$iterator = &new MyStubIterator(); -</strong> -</pre> - This is not very useful in itself as there would be no difference - in this class and the default except for the name. - However we can also add additional methods not found in the - original interface... -<pre> -class Iterator { -} -<strong>Stub::generate('Iterator', 'PrototypeIterator', array('next', 'isError')); -$iterator = &new PrototypeIterator(); -$iterator->setReturnValue('next', 0); -</strong> -</pre> - The <span class="new_code">next()</span> and - <span class="new_code">isError()</span> methods can now have - return values set just as if they existed in the original class. - </p> - <p> - One other esoteric way of customising the stubs is to change - the default wildcard used for parameter matching. -<pre> -<strong>Stub::generate('Connection'); -$iterator = &new StubConnection('wild'); -$iterator->setReturnValue('query', array('id' => 33), array('wild')); -</strong> -</pre> - The only reason to do this is if you genuinely wanted to test - against the literal string "*" and didn't want it - interpreted as "any". - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/unit_test_documentation.html b/tests/test_tools/simpletest/docs/en/unit_test_documentation.html deleted file mode 100755 index 47b61eca..00000000 --- a/tests/test_tools/simpletest/docs/en/unit_test_documentation.html +++ /dev/null @@ -1,390 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>SimpleTest for PHP regression test documentation</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<span class="chosen">Unit tester</span> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<a href="web_tester_documentation.html">Web tester</a> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>PHP Unit Test documentation</h1> -<div class="content"> - <p> -<a class="target" name="unit"> -<h2>Unit test cases</h2> -</a> -</p> - <p> - The core system is a regression testing framework built around - test cases. - A sample test case looks like this... -<pre> -<strong>class FileTestCase extends UnitTestCase { -}</strong> -</pre> - If no test name is supplied when chaining the constructor then - the class name will be taken instead. - This will be the name displayed in the test results. - </p> - <p> - Actual tests are added as methods in the test case whose names - by default start with the string "test" and - when the test case is invoked all such methods are run in - the order that PHP introspection finds them. - As many test methods can be added as needed. - For example... -<pre> -require_once('../classes/writer.php'); - -class FileTestCase extends UnitTestCase { - function FileTestCase() { - $this->UnitTestCase('File test'); - }<strong> - - function setUp() { - @unlink('../temp/test.txt'); - } - - function tearDown() { - @unlink('../temp/test.txt'); - } - - function testCreation() { - $writer = &new FileWriter('../temp/test.txt'); - $writer->write('Hello'); - $this->assertTrue(file_exists('../temp/test.txt'), 'File created'); - }</strong> -} -</pre> - The constructor is optional and usually omitted. - Without a name, the class name is taken as the name of the test case. - </p> - <p> - Our only test method at the moment is <span class="new_code">testCreation()</span> - where we check that a file has been created by our - <span class="new_code">Writer</span> object. - We could have put the <span class="new_code">unlink()</span> - code into this method as well, but by placing it in - <span class="new_code">setUp()</span> and - <span class="new_code">tearDown()</span> we can use it with - other test methods that we add. - </p> - <p> - The <span class="new_code">setUp()</span> method is run - just before each and every test method. - <span class="new_code">tearDown()</span> is run just after - each and every test method. - </p> - <p> - You can place some test case set up into the constructor to - be run once for all the methods in the test case, but - you risk test inteference that way. - This way is slightly slower, but it is safer. - Note that if you come from a JUnit background this will not - be the behaviour you are used to. - JUnit surprisingly reinstantiates the test case for each test - method to prevent such interference. - SimpleTest requires the end user to use <span class="new_code">setUp()</span>, but - supplies additional hooks for library writers. - </p> - <p> - The means of reporting test results (see below) are by a - visiting display class - that is notified by various <span class="new_code">assert...()</span> - methods. - Here is the full list for the <span class="new_code">UnitTestCase</span> - class, the default for SimpleTest... - <table> -<tbody> - <tr> -<td><span class="new_code">assertTrue($x)</span></td><td>Fail if $x is false</td> -</tr> - <tr> -<td><span class="new_code">assertFalse($x)</span></td><td>Fail if $x is true</td> -</tr> - <tr> -<td><span class="new_code">assertNull($x)</span></td><td>Fail if $x is set</td> -</tr> - <tr> -<td><span class="new_code">assertNotNull($x)</span></td><td>Fail if $x not set</td> -</tr> - <tr> -<td><span class="new_code">assertIsA($x, $t)</span></td><td>Fail if $x is not the class or type $t</td> -</tr> - <tr> -<td><span class="new_code">assertNotA($x, $t)</span></td><td>Fail if $x is of the class or type $t</td> -</tr> - <tr> -<td><span class="new_code">assertEqual($x, $y)</span></td><td>Fail if $x == $y is false</td> -</tr> - <tr> -<td><span class="new_code">assertNotEqual($x, $y)</span></td><td>Fail if $x == $y is true</td> -</tr> - <tr> -<td><span class="new_code">assertWithinMargin($x, $y, $m)</span></td><td>Fail if abs($x - $y) < $m is false</td> -</tr> - <tr> -<td><span class="new_code">assertOutsideMargin($x, $y, $m)</span></td><td>Fail if abs($x - $y) < $m is true</td> -</tr> - <tr> -<td><span class="new_code">assertIdentical($x, $y)</span></td><td>Fail if $x == $y is false or a type mismatch</td> -</tr> - <tr> -<td><span class="new_code">assertNotIdentical($x, $y)</span></td><td>Fail if $x == $y is true and types match</td> -</tr> - <tr> -<td><span class="new_code">assertReference($x, $y)</span></td><td>Fail unless $x and $y are the same variable</td> -</tr> - <tr> -<td><span class="new_code">assertCopy($x, $y)</span></td><td>Fail if $x and $y are the same variable</td> -</tr> - <tr> -<td><span class="new_code">assertPattern($p, $x)</span></td><td>Fail unless the regex $p matches $x</td> -</tr> - <tr> -<td><span class="new_code">assertNoPattern($p, $x)</span></td><td>Fail if the regex $p matches $x</td> -</tr> - <tr> -<td><span class="new_code">assertNoErrors()</span></td><td>Fail if any PHP error occoured</td> -</tr> - <tr> -<td><span class="new_code">assertError($x)</span></td><td>Fail if no PHP error or incorrect message/expectation</td> -</tr> - <tr> -<td><span class="new_code">assertExpectation($e)</span></td><td>Fail on failed expectation object</td> -</tr> - </tbody> -</table> - All assertion methods can take an optional description to - label the displayed result with. - If omitted a default message is sent instead which is usually - sufficient. - This default message can still be embedded in your own message - if you include "%s" within the string. - All the assertions return true on a pass or false on failure. - </p> - <p> - Some examples... -<pre> -<strong>$variable = null; -$this->assertNull($variable, 'Should be cleared');</strong> -</pre> - ...will pass and normally show no message. - If you have - <a href="http://www.lastcraft.com/display_subclass_tutorial.php">set up the tester to display passes</a> - as well then the message will be displayed as is. -<pre> -<strong>$this->assertIdentical(0, false, 'Zero is not false [%s]');</strong> -</pre> - This will fail as it performs a type - check as well as a comparison between the two values. - The "%s" part is replaced by the default - error message that would have been shown if we had not - supplied our own. - This also allows us to nest test messages. -<pre> -<strong>$a = 1; -$b = $a; -$this->assertReference($a, $b);</strong> -</pre> - Will fail as the variable <span class="new_code">$a</span> is a copy of <span class="new_code">$b</span>. -<pre> -<strong>$this->assertPattern('/hello/i', 'Hello world');</strong> -</pre> - This will pass as using a case insensitive match the string - <span class="new_code">hello</span> is contained in <span class="new_code">Hello world</span>. -<pre> -<strong>trigger_error('Disaster'); -trigger_error('Catastrophe'); -$this->assertError(); -$this->assertError('Catastrophe'); -$this->assertNoErrors();</strong> -</pre> - This one takes some explanation as in fact they all pass! - </p> - <p> - PHP errors in SimpleTest are trapped and placed in a queue. - Here the first error check catches the "Disaster" - message without checking the text and passes. - This removes the error from the queue. - The next error check tests not only the existence of the error, - but also the text which here matches so another pass. - With the queue now empty the last test will pass as well. - If any unchecked errors are left at the end of a test method then - an exception will be reported in the test. - Note that SimpleTest cannot catch compile time PHP errors. - </p> - <p> - The test cases also have some convenience methods for debugging - code or extending the suite... - <table> -<tbody> - <tr> -<td><span class="new_code">setUp()</span></td><td>Runs this before each test method</td> -</tr> - <tr> -<td><span class="new_code">tearDown()</span></td><td>Runs this after each test method</td> -</tr> - <tr> -<td><span class="new_code">pass()</span></td><td>Sends a test pass</td> -</tr> - <tr> -<td><span class="new_code">fail()</span></td><td>Sends a test failure</td> -</tr> - <tr> -<td><span class="new_code">error()</span></td><td>Sends an exception event</td> -</tr> - <tr> -<td><span class="new_code">sendMessage()</span></td><td>Sends a status message to those displays that support it</td> -</tr> - <tr> -<td><span class="new_code">signal($type, $payload)</span></td><td>Sends a user defined message to the test reporter</td> -</tr> - <tr> -<td><span class="new_code">dump($var)</span></td><td>Does a formatted <span class="new_code">print_r()</span> for quick and dirty debugging</td> -</tr> - <tr> -<td><span class="new_code">swallowErrors()</span></td><td>Clears the error queue</td> -</tr> - </tbody> -</table> - </p> - - <p> -<a class="target" name="extending_unit"> -<h2>Extending test cases</h2> -</a> -</p> - <p> - Of course additional test methods can be added to create - specific types of test case too so as to extend framework... -<pre> -require_once('simpletest/unit_tester.php'); -<strong> -class FileTester extends UnitTestCase { - function FileTester($name = false) { - $this->UnitTestCase($name); - } - - function assertFileExists($filename, $message = '%s') { - $this->assertTrue( - file_exists($filename), - sprintf($message, 'File [$filename] existence check')); - }</strong> -} -</pre> - Here the SimpleTest library is held in a folder called - <em>simpletest</em> that is local. - Substitute your own path for this. - </p> - <p> - This new case can be now be inherited just like - a normal test case... -<pre> -class FileTestCase extends <strong>FileTester</strong> { - - function setUp() { - @unlink('../temp/test.txt'); - } - - function tearDown() { - @unlink('../temp/test.txt'); - } - - function testCreation() { - $writer = &new FileWriter('../temp/test.txt'); - $writer->write('Hello');<strong> - $this->assertFileExists('../temp/test.txt');</strong> - } -} -</pre> - </p> - <p> - If you want a test case that does not have all of the - <span class="new_code">UnitTestCase</span> assertions, - only your own and <span class="new_code">assertTrue()</span>, - you need to extend the <span class="new_code">SimpleTestCase</span> - class instead. - It is found in <em>simple_test.php</em> rather than - <em>unit_tester.php</em>. - See <a href="group_test_documentation.html">later</a> if you - want to incorporate other unit tester's - test cases in your test suites. - </p> - - <p> -<a class="target" name="running_unit"> -<h2>Running a single test case</h2> -</a> -</p> - <p> - You won't often run single test cases except when bashing - away at a module that is having difficulty and you don't - want to upset the main test suite. - Here is the scaffolding needed to run the a lone test case... -<pre> -<?php - require_once('simpletest/unit_tester.php');<strong> - require_once('simpletest/reporter.php');</strong> - require_once('../classes/writer.php'); - - class FileTestCase extends UnitTestCase { - function FileTestCase() { - $this->UnitTestCase('File test'); - } - }<strong> - - $test = &new FileTestCase(); - $test->run(new HtmlReporter());</strong> -?> -</pre> - This script will run as is, but will output zero passes - and zero failures until test methods are added. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> diff --git a/tests/test_tools/simpletest/docs/en/web_tester_documentation.html b/tests/test_tools/simpletest/docs/en/web_tester_documentation.html deleted file mode 100755 index 99dacacc..00000000 --- a/tests/test_tools/simpletest/docs/en/web_tester_documentation.html +++ /dev/null @@ -1,511 +0,0 @@ -<html> -<head> -<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> -<title>Simple Test for PHP web script testing documentation</title> -<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> -</head> -<body> -<div class="menu_back"> -<div class="menu"> -<h2> -<a href="index.html">SimpleTest</a> -</h2> -<ul> -<li> -<a href="overview.html">Overview</a> -</li> -<li> -<a href="unit_test_documentation.html">Unit tester</a> -</li> -<li> -<a href="group_test_documentation.html">Group tests</a> -</li> -<li> -<a href="mock_objects_documentation.html">Mock objects</a> -</li> -<li> -<a href="partial_mocks_documentation.html">Partial mocks</a> -</li> -<li> -<a href="reporter_documentation.html">Reporting</a> -</li> -<li> -<a href="expectation_documentation.html">Expectations</a> -</li> -<li> -<span class="chosen">Web tester</span> -</li> -<li> -<a href="form_testing_documentation.html">Testing forms</a> -</li> -<li> -<a href="authentication_documentation.html">Authentication</a> -</li> -<li> -<a href="browser_documentation.html">Scriptable browser</a> -</li> -</ul> -</div> -</div> -<h1>Web tester documentation</h1> -<div class="content"> - <p> -<a class="target" name="fetch"> -<h2>Fetching a page</h2> -</a> -</p> - <p> - Testing classes is all very well, but PHP is predominately - a language for creating functionality within web pages. - How do we test the front end presentation role of our PHP - applications? - Well the web pages are just text, so we should be able to - examine them just like any other test data. - </p> - <p> - This leads to a tricky issue. - If we test at too low a level, testing for matching tags - in the page with pattern matching for example, our tests will - be brittle. - The slightest change in layout could break a large number of - tests. - If we test at too high a level, say using mock versions of a - template engine, then we lose the ability to automate some classes - of test. - For example, the interaction of forms and navigation will - have to be tested manually. - These types of test are extremely repetitive and error prone. - </p> - <p> - SimpleTest includes a special form of test case for the testing - of web page actions. - The <span class="new_code">WebTestCase</span> includes facilities - for navigation, content and cookie checks and form handling. - Usage of these test cases is similar to the - <a href="unit_tester_documentation.html">UnitTestCase</a>... -<pre> -<strong>class TestOfLastcraft extends WebTestCase { -}</strong> -</pre> - Here we are about to test the - <a href="http://www/lastcraft.com/">Last Craft</a> site itself. - If this test case is in a file called <em>lastcraft_test.php</em> - then it can be loaded in a runner script just like unit tests... -<pre> -<?php<strong> - require_once('simpletest/web_tester.php');</strong> - require_once('simpletest/reporter.php'); - - $test = &new GroupTest('Web site tests');<strong> - $test->addTestFile('lastcraft_test.php');</strong> - exit ($test->run(new TextReporter()) ? 0 : 1); -?> -</pre> - I am using the text reporter here to more clearly - distinguish the web content from the test output. - </p> - <p> - Nothing is being tested yet. - We can fetch the home page by using the - <span class="new_code">get()</span> method... -<pre> -class TestOfLastcraft extends WebTestCase { - <strong> - function testHomepage() { - $this->assertTrue($this->get('http://www.lastcraft.com/')); - }</strong> -} -</pre> - The <span class="new_code">get()</span> method will - return true only if page content was successfully - loaded. - It is a simple, but crude way to check that a web page - was actually delivered by the web server. - However that content may be a 404 response and yet - our <span class="new_code">get()</span> method will still return true. - </p> - <p> - Assuming that the web server for the Last Craft site is up - (sadly not always the case), we should see... -<pre class="shell"> -Web site tests -OK -Test cases run: 1/1, Failures: 0, Exceptions: 0 -</pre> - All we have really checked is that any kind of page was - returned. - We don't yet know if it was the right one. - </p> - - <p> -<a class="target" name="content"> -<h2>Testing page content</h2> -</a> -</p> - <p> - To confirm that the page we think we are on is actually the - page we are on, we need to verify the page content. -<pre> -class TestOfLastcraft extends WebTestCase { - - function testHomepage() {<strong> - $this->get('http://www.lastcraft.com/'); - $this->assertTest('Why the last craft');</strong> - } -} -</pre> - The page from the last fetch is held in a buffer in - the test case, so there is no need to refer to it directly. - The pattern match is always made against the buffer. - </p> - <p> - Here is the list of possible content assertions... - <table> -<tbody> - <tr> -<td><span class="new_code">assertTitle($title)</span></td><td>Pass if title is an exact match</td> -</tr> - <tr> -<td><span class="new_code">assertPattern($pattern)</span></td><td>A Perl pattern match against the page content</td> -</tr> - <tr> -<td><span class="new_code">assertNoPattern($pattern)</span></td><td>A Perl pattern match to not find content</td> -</tr> - <tr> -<td><span class="new_code">assertText($text)</span></td><td>Pass if matches visible and "alt" text</td> -</tr> - <tr> -<td><span class="new_code">assertNoText($text)</span></td><td>Pass if doesn't match visible and "alt" text</td> -</tr> - <tr> -<td><span class="new_code">assertLink($label)</span></td><td>Pass if a link with this text is present</td> -</tr> - <tr> -<td><span class="new_code">assertNoLink($label)</span></td><td>Pass if no link with this text is present</td> -</tr> - <tr> -<td><span class="new_code">assertLinkById($id)</span></td><td>Pass if a link with this id attribute is present</td> -</tr> - <tr> -<td><span class="new_code">assertNoLinkById($id)</span></td><td>Pass if no link with this id attribute is present</td> -</tr> - <tr> -<td><span class="new_code">assertField($name, $value)</span></td><td>Pass if an input tag with this name has this value</td> -</tr> - <tr> -<td><span class="new_code">assertFieldById($id, $value)</span></td><td>Pass if an input tag with this id has this value</td> -</tr> - <tr> -<td><span class="new_code">assertResponse($codes)</span></td><td>Pass if HTTP response matches this list</td> -</tr> - <tr> -<td><span class="new_code">assertMime($types)</span></td><td>Pass if MIME type is in this list</td> -</tr> - <tr> -<td><span class="new_code">assertAuthentication($protocol)</span></td><td>Pass if the current challenge is this protocol</td> -</tr> - <tr> -<td><span class="new_code">assertNoAuthentication()</span></td><td>Pass if there is no current challenge</td> -</tr> - <tr> -<td><span class="new_code">assertRealm($name)</span></td><td>Pass if the current challenge realm matches</td> -</tr> - <tr> -<td><span class="new_code">assertHeader($header, $content)</span></td><td>Pass if a header was fetched matching this value</td> -</tr> - <tr> -<td><span class="new_code">assertNoHeader($header)</span></td><td>Pass if a header was not fetched</td> -</tr> - <tr> -<td><span class="new_code">assertCookie($name, $value)</span></td><td>Pass if there is currently a matching cookie</td> -</tr> - <tr> -<td><span class="new_code">assertNoCookie($name)</span></td><td>Pass if there is currently no cookie of this name</td> -</tr> - </tbody> -</table> - As usual with the SimpleTest assertions, they all return - false on failure and true on pass. - They also allow an optional test message and you can embed - the original test message inside using "%s" inside - your custom message. - </p> - <p> - So now we could instead test against the title tag with... -<pre> -<strong>$this->assertTitle('The Last Craft? Web developer tutorials on PHP, Extreme programming and Object Oriented development');</strong> -</pre> - ...or, if that is too long and fragile... -<pre> -<strong>$this->assertTitle(new PatternExpectation('/The Last Craft/'));</strong> -</pre> - As well as the simple HTML content checks we can check - that the MIME type is in a list of allowed types with... -<pre> -<strong>$this->assertMime(array('text/plain', 'text/html'));</strong> -</pre> - More interesting is checking the HTTP response code. - Like the MIME type, we can assert that the response code - is in a list of allowed values... -<pre> -class TestOfLastcraft extends WebTestCase { - - function testRedirects() { - $this->get('http://www.lastcraft.com/test/redirect.php'); - $this->assertResponse(200);</strong> - } -} -</pre> - Here we are checking that the fetch is successful by - allowing only a 200 HTTP response. - This test will pass, but it is not actually correct to do so. - There is no page, instead the server issues a redirect. - The <span class="new_code">WebTestCase</span> will - automatically follow up to three such redirects. - The tests are more robust this way and we are usually - interested in the interaction with the pages rather - than their delivery. - If the redirects are of interest then this ability must - be disabled... -<pre> -class TestOfLastcraft extends WebTestCase { - - function testHomepage() {<strong> - $this->setMaximumRedirects(0);</strong> - $this->get('http://www.lastcraft.com/test/redirect.php'); - $this->assertResponse(200); - } -} -</pre> - The assertion now fails as expected... -<pre class="shell"> -Web site tests -1) Expecting response in [200] got [302] - in testhomepage - in testoflastcraft - in lastcraft_test.php -FAILURES!!! -Test cases run: 1/1, Failures: 1, Exceptions: 0 -</pre> - We can modify the test to correctly assert redirects with... -<pre> -class TestOfLastcraft extends WebTestCase { - - function testHomepage() { - $this->setMaximumRedirects(0); - $this->get('http://www.lastcraft.com/test/redirect.php'); - $this->assertResponse(<strong>array(301, 302, 303, 307)</strong>); - } -} -</pre> - This now passes. - </p> - - <p> -<a class="target" name="navigation"> -<h2>Navigating a web site</h2> -</a> -</p> - <p> - Users don't often navigate sites by typing in URLs, but by - clicking links and buttons. - Here we confirm that the contact details can be reached - from the home page... -<pre> -class TestOfLastcraft extends WebTestCase { - ... - function testContact() { - $this->get('http://www.lastcraft.com/');<strong> - $this->clickLink('About'); - $this->assertTitle(new PatternExpectation('/About Last Craft/'));</strong> - } -} -</pre> - The parameter is the text of the link. - </p> - <p> - If the target is a button rather than an anchor tag, then - <span class="new_code">clickSubmit()</span> can be used - with the button title... -<pre> -<strong>$this->clickSubmit('Go!');</strong> -</pre> - If you are not sure or don't care, the usual case, then just - use the <span class="new_code">click()</span> method... -<pre> -<strong>$this->click('Go!');</strong> -</pre> - </p> - <p> - The list of navigation methods is... - <table> -<tbody> - <tr> -<td><span class="new_code">getUrl()</span></td><td>The current location</td> -</tr> - <tr> -<td><span class="new_code">get($url, $parameters)</span></td><td>Send a GET request with these parameters</td> -</tr> - <tr> -<td><span class="new_code">post($url, $parameters)</span></td><td>Send a POST request with these parameters</td> -</tr> - <tr> -<td><span class="new_code">head($url, $parameters)</span></td><td>Send a HEAD request without replacing the page content</td> -</tr> - <tr> -<td><span class="new_code">retry()</span></td><td>Reload the last request</td> -</tr> - <tr> -<td><span class="new_code">back()</span></td><td>Like the browser back button</td> -</tr> - <tr> -<td><span class="new_code">forward()</span></td><td>Like the browser forward button</td> -</tr> - <tr> -<td><span class="new_code">authenticate($name, $password)</span></td><td>Retry after a challenge</td> -</tr> - <tr> -<td><span class="new_code">restart()</span></td><td>Restarts the browser as if a new session</td> -</tr> - <tr> -<td><span class="new_code">getCookie($name)</span></td><td>Gets the cookie value for the current context</td> -</tr> - <tr> -<td><span class="new_code">ageCookies($interval)</span></td><td>Ages current cookies prior to a restart</td> -</tr> - <tr> -<td><span class="new_code">clearFrameFocus()</span></td><td>Go back to treating all frames as one page</td> -</tr> - <tr> -<td><span class="new_code">clickSubmit($label)</span></td><td>Click the first button with this label</td> -</tr> - <tr> -<td><span class="new_code">clickSubmitByName($name)</span></td><td>Click the button with this name attribute</td> -</tr> - <tr> -<td><span class="new_code">clickSubmitById($id)</span></td><td>Click the button with this ID attribute</td> -</tr> - <tr> -<td><span class="new_code">clickImage($label, $x, $y)</span></td><td>Click an input tag of type image by title or alt text</td> -</tr> - <tr> -<td><span class="new_code">clickImageByName($name, $x, $y)</span></td><td>Click an input tag of type image by name</td> -</tr> - <tr> -<td><span class="new_code">clickImageById($id, $x, $y)</span></td><td>Click an input tag of type image by ID attribute</td> -</tr> - <tr> -<td><span class="new_code">submitFormById($id)</span></td><td>Submit a form without the submit value</td> -</tr> - <tr> -<td><span class="new_code">clickLink($label, $index)</span></td><td>Click an anchor by the visible label text</td> -</tr> - <tr> -<td><span class="new_code">clickLinkById($id)</span></td><td>Click an anchor by the ID attribute</td> -</tr> - <tr> -<td><span class="new_code">getFrameFocus()</span></td><td>The name of the currently selected frame</td> -</tr> - <tr> -<td><span class="new_code">setFrameFocusByIndex($choice)</span></td><td>Focus on a frame counting from 1</td> -</tr> - <tr> -<td><span class="new_code">setFrameFocus($name)</span></td><td>Focus on a frame by name</td> -</tr> - </tbody> -</table> - </p> - <p> - The parameters in the <span class="new_code">get()</span>, <span class="new_code">post()</span> or - <span class="new_code">head()</span> methods are optional. - The HTTP HEAD fetch does not change the browser context, only loads - cookies. - This can be useful for when an image or stylesheet sets a cookie - for crafty robot blocking. - </p> - <p> - The <span class="new_code">retry()</span>, <span class="new_code">back()</span> and - <span class="new_code">forward()</span> commands work as they would on - your web browser. - They use the history to retry pages. - This can be handy for checking the effect of hitting the - back button on your forms. - </p> - <p> - The frame methods need a little explanation. - By default a framed page is treated just like any other. - Content will be searced for throughout the entire frameset, - so clicking a link will work no matter which frame - the anchor tag is in. - You can override this behaviour by focusing on a single - frame. - If you do that, all searches and actions will apply to that - frame alone, such as authentication and retries. - If a link or button is not in a focused frame then it cannot - be clicked. - </p> - <p> - Testing navigation on fixed pages only tells you when you - have broken an entire script. - For highly dynamic pages, such as for bulletin boards, this can - be crucial for verifying the correctness of the application. - For most applications though, the really tricky logic is usually in - the handling of forms and sessions. - Fortunately SimpleTest includes - <a href="form_testing_documentation.html">tools for testing web forms</a> - as well. - </p> - - <p> -<a class="target" name="request"> -<h2>Modifying the request</h2> -</a> -</p> - <p> - Although SimpleTest does not have the goal of testing networking - problems, it does include some methods to modify and debug - the requests it makes. - Here is another method list... - <table> -<tbody> - <tr> -<td><span class="new_code">getTransportError()</span></td><td>The last socket error</td> -</tr> - <tr> -<td><span class="new_code">showRequest()</span></td><td>Dump the outgoing request</td> -</tr> - <tr> -<td><span class="new_code">showHeaders()</span></td><td>Dump the incoming headers</td> -</tr> - <tr> -<td><span class="new_code">showSource()</span></td><td>Dump the raw HTML page content</td> -</tr> - <tr> -<td><span class="new_code">ignoreFrames()</span></td><td>Do not load framesets</td> -</tr> - <tr> -<td><span class="new_code">setCookie($name, $value)</span></td><td>Set a cookie from now on</td> -</tr> - <tr> -<td><span class="new_code">addHeader($header)</span></td><td>Always add this header to the request</td> -</tr> - <tr> -<td><span class="new_code">setMaximumRedirects($max)</span></td><td>Stop after this many redirects</td> -</tr> - <tr> -<td><span class="new_code">setConnectionTimeout($timeout)</span></td><td>Kill the connection after this time between bytes</td> -</tr> - <tr> -<td><span class="new_code">useProxy($proxy, $name, $password)</span></td><td>Make requests via this proxy URL</td> -</tr> - </tbody> -</table> - These methods are principally for debugging. - </p> - - </div> -<div class="copyright"> - Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 - </div> -</body> -</html> |