diff options
Diffstat (limited to '3rdparty/simpletest/docs')
26 files changed, 12068 insertions, 0 deletions
diff --git a/3rdparty/simpletest/docs/en/authentication_documentation.html b/3rdparty/simpletest/docs/en/authentication_documentation.html new file mode 100644 index 00000000000..e058e19a111 --- /dev/null +++ b/3rdparty/simpletest/docs/en/authentication_documentation.html @@ -0,0 +1,378 @@ +<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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <span class="chosen">Authentication</span> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Authentication documentation</h1> + This page... + <ul> +<li> + Getting through <a href="#basic">Basic HTTP authentication</a> + </li> +<li> + Testing <a href="#cookies">cookie based authentication</a> + </li> +<li> + Managing <a href="#session">browser sessions</a> and timeouts + </li> +</ul> +<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> + + <h2> +<a class="target" name="basic"></a>Basic HTTP authentication</h2> + <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> +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> + This type of test, testing HTTP responses, is not typical. + </p> + <p> + 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> + If you want, 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. + I'm afraid we leave this up to you. + </p> + <p> + A problem with encoding the login details directly in the URL is + the authentication header will not be sent on subsequent requests. + If you navigate with relative URLs though, the authentication + information will be preserved along with the domain name. + </p> + <p> + Normally though, you use the <span class="new_code">authenticate()</span> call. + SimpleTest will then remember your login information on each request. + </p> + <p> + Only testing with basic authentication is currently supported, and + this is only really secure in tandem with HTTPS connections. + This is usually good enough to protect test server from prying eyes, + however. + Digest authentication and NTLM authentication may be added + in the future if enough people request this feature. + </p> + + <h2> +<a class="target" name="cookies"></a>Cookies</h2> + <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 with complicated timeouts. + We need to be able to test this too. + </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> + If you are using PHP to handle sessions for you then + this test is even more useless, as we are just testing PHP itself. + </p> + <p> + The simplest test of logging in is to visually inspect the + next page to see if you are really logged in. + Just test the next page with <span class="new_code">WebTestCase::assertText()</span>. + </p> + <p> + The test is similar to any other form test, + 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 and we haven't accidently reset it. + </p> + <p> + We could even attempt to hack 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> + + <h2> +<a class="target" name="session"></a>Browser sessions</h2> + <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 waiting + for the cookie to pass 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> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest download page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + The <a href="http://simpletest.org/api/">developer's API for SimpleTest</a> + gives full detail on the classes and assertions available. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <span class="chosen">Authentication</span> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/browser_documentation.html b/3rdparty/simpletest/docs/en/browser_documentation.html new file mode 100644 index 00000000000..809c1431137 --- /dev/null +++ b/3rdparty/simpletest/docs/en/browser_documentation.html @@ -0,0 +1,501 @@ +<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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <span class="chosen">Scriptable browser</span> +</div></div> +<h1>PHP Scriptable Web Browser</h1> + This page... + <ul> +<li> + Using the bundled <a href="#scripting">web browser in scripts</a> + </li> +<li> + <a href="#debug">Debugging</a> failed pages + </li> +<li> + Complex <a href="#unit">tests with multiple web browsers</a> + </li> +</ul> +<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> + + <h2> +<a class="target" name="scripting"></a>The Scriptable Browser</h2> + <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. + <p> + </p> + Methods such as periodic scraping 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">click($label)</span></td> +<td>Clicks visible link or button text</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">clickLinkById($id)</span></td> +<td>Follows a link by attribute</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($label, $value)</span></td> +<td>Sets all form fields with that label or name</td> +</tr> + <tr> +<td><span class="new_code">setFieldByName($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($label)</span></td> +<td>Accessor for a form element value by label tag and then name</td> +</tr> + <tr> +<td><span class="new_code">getFieldByName($name)</span></td> +<td>Accessor for a form element value using name attribute</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 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>Clicks an input tag of type image by name</td> +</tr> + <tr> +<td><span class="new_code">clickImageById($id, $x, $y)</span></td> +<td>Clicks an input tag of type image by ID 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 many methods to list available links and fields. + <table><tbody> + <tr> +<td><span class="new_code">isClickable($label)</span></td> +<td>Test to see if a click target exists by label or name</td> +</tr> + <tr> +<td><span class="new_code">isSubmit($label)</span></td> +<td>Test for the existence of a button with that label or name</td> +</tr> + <tr> +<td><span class="new_code">isImage($label)</span></td> +<td>Test for the existence of an image button with that label or name</td> +</tr> + <tr> +<td><span class="new_code">getLink($label)</span></td> +<td>Finds a URL from its label</td> +</tr> + <tr> +<td><span class="new_code">getLinkById($label)</span></td> +<td>Finds a URL from its ID attribute</td> +</tr> + <tr> +<td><span class="new_code">getUrls()</span></td> +<td>Lists available links in the current page</td> +</tr> + </tbody></table> + This will be expanded in later versions of SimpleTest. + </p> + <p> + Frames are a rather esoteric feature these days, but SimpleTest has + retained support for them. + </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> + + <h2> +<a class="target" name="debug"></a>What went wrong?</h2> + <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">getUrl()</span></td> +<td>Url of most recent page fetched</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">getBaseUrl()</span></td> +<td>Base url only of most recent page fetched</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> + + <h2> +<a class="target" name="unit"></a>Complex unit tests with multiple browsers</h2> + <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 could 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_attempt = new SimpleBrowser(); + $first_attempt->get('http://my-site.com/login.php'); + $first_attempt->setField('name', 'Me'); + $first_attempt->setField('password', 'Secret'); + $first_attempt->click('Enter'); + $this->assertEqual($first_attempt->getTitle(), 'Welcome'); + + $second_attempt = new SimpleBrowser(); + $second_attempt->get('http://my-site.com/login.php'); + $second_attempt->setField('name', 'Me'); + $second_attempt->setField('password', 'Secret'); + $second_attempt->click('Enter'); + $this->assertEqual($second_attempt->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, such as PHPUnit. + </p> + + </div> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest download page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + The <a href="http://simpletest.org/api/">developer's API for SimpleTest</a> + gives full detail on the classes and assertions available. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <span class="chosen">Scriptable browser</span> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/docs.css b/3rdparty/simpletest/docs/en/docs.css new file mode 100755 index 00000000000..18368a04f7a --- /dev/null +++ b/3rdparty/simpletest/docs/en/docs.css @@ -0,0 +1,121 @@ +body { + padding-left: 3%; + padding-right: 3%; +} +h1, h2, h3 { + font-family: sans-serif; +} +h1 { + text-align: center; +} +pre { + font-family: "courier new", courier, typewriter, monospace; + font-size: 90%; + border: 1px solid; + border-color: #999966; + background-color: #ffffcc; + padding: 5px; + margin-left: 20px; + margin-right: 40px; +} +.code, .new_code, pre.new_code { + font-family: "courier new", courier, typewriter, monospace; + font-weight: bold; +} +div.copyright { + font-size: 80%; + color: gray; +} +div.copyright a { + margin-top: 1em; + color: gray; +} +ul.api { + border: 2px outset; + border-color: gray; + background-color: white; + margin: 5px; + margin-left: 5%; + margin-right: 5%; +} +ul.api li { + margin-top: 0.2em; + margin-bottom: 0.2em; + list-style: none; + text-indent: -3em; + padding-left: 1em; +} +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; +} +div.menu { + text-align: center; +} +table { + border: 2px outset; + border-color: gray; + background-color: white; + margin: 5px; + margin-left: 5%; + margin-right: 5%; +} +td { + font-size: 90%; +} +.shell { + color: white; +} +pre.shell { + border: 4px ridge; + border-color: gray; + padding: 10px; + margin: 5px; + margin-left: 20px; + margin-right: 40px; + background-color: #000100; + color: #99ff99; + font-size: 90%; +} +pre.file { + color: black; + border: 1px solid; + border-color: black; + padding: 10px; + margin: 5px; + margin-left: 20px; + margin-right: 40px; + background-color: white; + font-size: 90%; +} +form.demo { + background-color: lightgray; + border: 4px outset; + border-color: lightgray; + padding: 10px; + margin-right: 40%; +} +dl, dd { + margin: 10px; + margin-left: 30px; +} +em { + font-weight: bold; + font-family: "courier new", courier, typewriter, monospace; +} diff --git a/3rdparty/simpletest/docs/en/expectation_documentation.html b/3rdparty/simpletest/docs/en/expectation_documentation.html new file mode 100644 index 00000000000..26704d5ae83 --- /dev/null +++ b/3rdparty/simpletest/docs/en/expectation_documentation.html @@ -0,0 +1,476 @@ +<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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <span class="chosen">Expectations</span> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Expectation documentation</h1> + This page... + <ul> +<li> + Using expectations for + <a href="#mock">more precise testing with mock objects</a> + </li> +<li> + <a href="#behaviour">Changing mock object behaviour</a> with expectations + </li> +<li> + <a href="#extending">Extending the expectations</a> + </li> +<li> + Underneath SimpleTest <a href="#unit">uses expectation classes</a> + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="mock"></a>More control over mock objects</h2> + <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);</strong> + } +} +</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">PatternExpectation</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">PatternExpectation</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">AnythingExpectation</span></td> +<td>Will always match</td> +</tr> + <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">WithinMarginExpectation</span></td> +<td>Compares a value to within a margin</td> +</tr> + <tr> +<td><span class="new_code">OutsideMarginExpectation</span></td> +<td>Checks that a value is out side the margin</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> + <tr> +<td><span class="new_code">TrueExpectation</span></td> +<td>Accepts any PHP variable that evaluates to true</td> +</tr> + <tr> +<td><span class="new_code">FalseExpectation</span></td> +<td>Accepts any PHP variable that evaluates to false</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> + Some examples... + </p> + <p> +<pre> +$mock->expectOnce('method', array(new IdenticalExpectation(14))); +</pre> + This is the same as <span class="new_code">$mock->expectOnce('method', array(14))</span>. +<pre> +$mock->expectOnce('method', array(new EqualExpectation(14))); +</pre> + This is different from the previous version in that the string + <span class="new_code">"14"</span> as a parameter will also pass. + Sometimes the additional type checks of SimpleTest are too restrictive. +<pre> +$mock->expectOnce('method', array(new AnythingExpectation(14))); +</pre> + This is the same as <span class="new_code">$mock->expectOnce('method', array('*'))</span>. +<pre> +$mock->expectOnce('method', array(new IdenticalExpectation('*'))); +</pre> + This is handy if you want to assert a literal <span class="new_code">"*"</span>. +<pre> +new NotIdenticalExpectation(14) +</pre> + This matches on anything other than integer 14. + Even the string <span class="new_code">"14"</span> would pass. +<pre> +new WithinMarginExpectation(14.0, 0.001) +</pre> + This will accept any value from 13.999 to 14.001 inclusive. + </p> + + <h2> +<a class="target" name="behaviour"></a>Using expectations to control stubs</h2> + <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 a mock authorisation server to simulate a successful login, + but only if it receives a valid session object. + We can do this as follows... +<pre> +Mock::generate('Authorisation'); +<strong> +$authorisation = new MockAuthorisation(); +$authorisation->returns( + 'isAllowed', + true, + array(new IsAExpectation('Session', 'Must be a session'))); +$authorisation->returns('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> + + <h2> +<a class="target" name="extending"></a>Creating your own expectations</h2> + <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> or further extend a subclass... +<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> + Here is a more typical example, matching part of a hash... +<pre> +<strong>class JustField extends EqualExpectation { + private $key; + + function __construct($key, $expected) { + parent::__construct($expected); + $this->key = $key; + } + + function test($compare) { + if (! isset($compare[$this->key])) { + return false; + } + return parent::test($compare[$this->key]); + } + + function testMessage($compare) { + if (! isset($compare[$this->key])) { + return 'Key [' . $this->key . '] does not exist'; + } + return 'Key [' . $this->key . '] -> ' . + parent::testMessage($compare[$this->key]); + } +}</strong> +</pre> + We tend to seperate message clauses with + "&nbsp;->&nbsp;". + This allows derivative tools to reformat the output. + </p> + <p> + Suppose some authenticator is expecting to be given + a database row corresponding to the user, and we + only need to confirm the username is correct. + We can assert just their username with... +<pre> +$mock->expectOnce('authenticate', + array(new JustKey('username', 'marcus'))); +</pre> + </p> + + <h2> +<a class="target" name="unit"></a>Under the bonnet of the unit tester</h2> + <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 generic + <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> + <span class="new_code">assert()</span> will test any expectation class directly. + </p> + <p> + 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 rare to need the expectations for more than pattern + matching, but these facilities do allow testers to build + some sort of domain language for testing their application. + Also, complex expectation classes could make the tests + harder to read and debug. + In effect extending the test framework to create their own tool set. + </p> + + </div> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest download page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + The expectations mimic the constraints in <a href="http://www.jmock.org/">JMock</a>. + </li> +<li> + <a href="http://simpletest.org/api/">Full API for SimpleTest</a> + from the PHPDoc. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <span class="chosen">Expectations</span> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/form_testing_documentation.html b/3rdparty/simpletest/docs/en/form_testing_documentation.html new file mode 100644 index 00000000000..328735c9dca --- /dev/null +++ b/3rdparty/simpletest/docs/en/form_testing_documentation.html @@ -0,0 +1,351 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>SimpleTest 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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <span class="chosen">Testing forms</span> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Form testing documentation</h1> + This page... + <ul> +<li> + Changing form values and successfully + <a href="#submit">Submitting a simple form</a> + </li> +<li> + Handling <a href="#multiple">widgets with multiple values</a> + by setting lists. + </li> +<li> + Bypassing javascript to <a href="#hidden-field">set a hidden field</a>. + </li> +<li> + <a href="#raw">Raw posting</a> when you don't have a button + to click. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="submit"></a>Submitting a simple form</h2> + <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 of a fixed + string. +<pre> +class SimpleFormTests extends WebTestCase { + function testDefaultValue() { + $this->get('http://www.lastcraft.com/form_testing_documentation.php'); + $this->assertField('a', <strong>new PatternExpectation('/default/')</strong>); + } +} +</pre> + 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. + In general SimpleTest tries to emulate typical browser behaviour as much as possible, + rather than attempting to catch any form of HTML omission. + 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, + or any of the HTML and CSS validators already out there. + </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 current selection will not be changed if the new value is not an option. + </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> + The browser emulation offered by SimpleTest mimics + the actions which can be perform by a user on a + standard HTML page. Javascript is not supported, and + it's unlikely that support will be added any time + soon. + </p> + <p> + Of particular note is that the Javascript idiom of + passing form results by setting a hidden field cannot + be performed using the normal SimpleTest + commands. See below for a way to test such forms. + </p> + + <h2> +<a class="target" name="multiple"></a>Fields with multiple values</h2> + <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> + + <h2> +<a class="target" name="hidden-field"></a>Forms which use javascript to set a hidden field</h2> + <p> + If you want to test a form which relies on javascript to set a hidden + field, you can't just call setField(). + The following code will <em>not</em> work: +<pre> +class SimpleFormTests extends WebTestCase { + function testEmulateMyJavascriptForm() { + <strong>// This does *not* work</strong> + $this->setField('a_hidden_field', '123'); + $this->clickSubmit('OK'); + } +} +</pre> + Instead, you need to pass the additional form parameters to the + clickSubmit() method: +<pre> +class SimpleFormTests extends WebTestCase { + function testMyJavascriptForm() { + <strong>$this->clickSubmit('OK', array('a_hidden_field'=>'123'));</strong> + } + +} +</pre> + Bear in mind that in doing this you're effectively stubbing out a + part of your software (the javascript code in the form), and + perhaps you might be better off using something like + <a href="http://selenium.openqa.org/">Selenium</a> to ensure a complete + test. + </p> + + <h2> +<a class="target" name="raw"></a>Raw posting</h2> + <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 emulating a form submission. + You would normally only do this as a temporary expedient, or where + you are expecting a 3rd party to submit to a form. + The exception is when you want tests to protect you from + attempts to spoof your pages. + </p> + + </div> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest download page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + The <a href="http://simpletest.org/api/">developer's API for SimpleTest</a> + gives full detail on the classes and assertions available. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <span class="chosen">Testing forms</span> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/group_test_documentation.html b/3rdparty/simpletest/docs/en/group_test_documentation.html new file mode 100644 index 00000000000..10f22a2b1b9 --- /dev/null +++ b/3rdparty/simpletest/docs/en/group_test_documentation.html @@ -0,0 +1,252 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>SimpleTest for PHP test suites</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <span class="chosen">Group tests</span> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Test suite documentation</h1> + This page... + <ul> +<li> + Different ways to <a href="#group">group tests</a> together. + </li> +<li> + Combining group tests into <a href="#higher">larger groups</a>. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="group"></a>Grouping tests into suites</h2> + <p> + There are many ways to group tests together into test suites. + One way is to simply place multiple test cases into a single file... +<pre> +<strong><?php +require_once(dirname(__FILE__) . '/simpletest/autorun.php'); +require_once(dirname(__FILE__) . '/../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 need none of the SimpleTest libraries. + </p> + <p> + Occasionally special subclasses are created that methods useful + for testing part of the application. + These new base classes are then used in place of <span class="new_code">UnitTestCase</span> + or <span class="new_code">WebTestCase</span>. + You don't normally want to run these as test cases. + Simply mark any base test cases that should not be run as abstract... +<pre> +<strong>abstract</strong> class MyFileTestCase extends UnitTestCase { + ... +} + +class FileTester extends MyFileTestCase { ... } + +class SocketTester extends UnitTestCase { ... } +</pre> + Here the <span class="new_code">FileTester</span> class does + not contain any actual tests, but is the base class for other + test cases. + </p> + <p> + We will call this sample <em>file_test.php</em>. + Currently the test cases are grouped simply by being in the same file. + We can build larger constructs just by including other test files in. +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('file_test.php'); +?> +</pre> + This will work, but create a purely flat hierarchy. + INstead we create a test suite file. + Our top level test suite can look like this... +<pre> +<?php +require_once('simpletest/autorun.php'); + +class AllFileTests extends TestSuite { + function __construct() { + parent::__construct(); + <strong>$this->addFile('file_test.php');</strong> + } +} +?> +</pre> + What happens here is that the <span class="new_code">TestSuite</span> + class will do 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 composes + them to the test suite. + This method gives us the most control as we just manually add + more test files as our test suite grows. + </p> + <p> + If this is too much typing, and you are willing to group + test suites together in their own directories or otherwise + tag the file names, then there is a more automatic way... +<pre> +<?php +require_once('simpletest/autorun.php'); + +class AllFileTests extends TestSuite { + function __construct() { + parent::__construct(); + $this->collect(dirname(__FILE__) . '/unit', + new SimplePatternCollector('/_test.php/')); + } +} +?> +</pre> + This will scan a directory called "unit" for any files + ending with "_test.php" and load them. + You don't have to use <span class="new_code">SimplePatternCollector</span> to + filter by a pattern in the filename, but this is the most common + usage. + </p> + <p> + That snippet above is very common in practice. + Now all you have to do is drop a file of test cases into the + directory and it will run just by running the test suite script. + </p> + <p> + The catch is that you cannot control the order in which the test + cases are run. + If you want to see lower level components fail first in the test suite, + and this will make diagnosis a lot easier, then you should manually + call <span class="new_code">addFile()</span> for these. + Tests cases are only loaded once, so it's fine to have these included + again by a directory scan. + </p> + <p> + Test cases loaded with the <span class="new_code">addFile</span> method have some + useful properties. + You can guarantee that the constructor is run + just before the first test method and the destructor + is run just after the last test method. + This allows you to place test case wide set up and tear down + code in the constructor and destructor, just like a normal + class. + </p> + + <h2> +<a class="target" name="higher"></a>Composite suites</h2> + <p> + The above method places all of the test cases into one large suite. + For larger projects though this may not be flexible enough; you + may want to group the tests together in all sorts of ways. + </p> + <p> + Everything we have described so far with test scripts applies to + <span class="new_code">TestSuite</span>s as well... +<pre> +<?php +require_once('simpletest/autorun.php'); +<strong> +class BigTestSuite extends TestSuite { + function __construct() { + parent::__construct(); + $this->addFile('file_tests.php'); + } +}</strong> +?> +</pre> + This effectively adds our test cases and a single suite below + the first. + When a test fails, we see the breadcrumb trail of the nesting. + We can even mix groups and test cases freely as long as + we are careful about loops in our includes. +<pre> +<?php +require_once('simpletest/autorun.php'); + +class BigTestSuite extends TestSuite { + function __construct() { + parent::__construct(); + $this->addFile('file_tests.php'); + <strong>$this->addFile('some_other_test.php');</strong> + } +} +?> +</pre> + Note that in the event of a double include, ony the first instance + of the test case will be run. + </p> + + </div> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest download page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <span class="chosen">Group tests</span> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/index.html b/3rdparty/simpletest/docs/en/index.html new file mode 100644 index 00000000000..9f022d6b10b --- /dev/null +++ b/3rdparty/simpletest/docs/en/index.html @@ -0,0 +1,542 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title> + Download the SimpleTest 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"> +<span class="chosen">SimpleTest</span> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>SimpleTest for PHP</h1> + This page... + <ul> +<li> + <a href="#unit">Using unit tester</a> + with an example. + </li> +<li> + <a href="#group">Grouping tests</a> + for testing with one click. + </li> +<li> + <a href="#mock">Using mock objects</a> + to ease testing and gain tighter control. + </li> +<li> + <a href="#web">Testing web pages</a> + at the browser level. + </li> +</ul> +<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> + + <h2> +<a class="target" name="unit"></a>Using the tester quickly</h2> + <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, and includes + <a href="http://www.mockobjects.com">mock objects</a>. + </p> + <p> + What makes this tool immediately useful to the PHP developer is the internal + web browser. + This allows tests that navigate web sites, fill in forms and test pages. + Being able to write these test in PHP means that it is easy to write + integrated tests. + An example might be confirming that a user was written to a database + after a signing up through the web site. + </p> + <p> + The quickest way to demonstrate SimpleTest 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/autorun.php');</strong> +require_once('../classes/log.php'); + +class TestOfLogging extends <strong>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 + unpacked the toolset. + The "autorun.php" file does more than just include the + SimpleTest files, it also runs our test for us. + </p> + <p> + The <span class="new_code">TestOfLogging</span> is our first test case and it's + currently empty. + Each test case is a class that extends one of the SimpleTet base classes + and we can have as many of these in the file as we want. + </p> + <p> + With three lines of scaffolding, and our <span class="new_code">Log</span> class + include, we have a test suite. + No tests though. + </p> + <p> + For our first test, 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/autorun.php'); +require_once('../classes/log.php'); + +class TestOfLogging extends UnitTestCase { + function <strong>testLogCreatesNewFileOnFirstMessage()</strong> { + @unlink('/temp/test.log'); + $log = new Log('/temp/test.log'); + <strong>$this->assertFalse(file_exists('/temp/test.log'));</strong> + $log->message('Should write this to a file'); + <strong>$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 "test" + and execute that method. + If the method starts "test", it's a test. + Note the very long name <span class="new_code">testLogCreatesNewFileOnFirstMessage()</span>. + This is considered good style and makes the test output more readable. + </p> + <p> + We would normally have more than one test method in a test case, + but that's for later. + </p> + <p> + 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 debugging content right next to the assertion concerned. + </p> + <p> + To see these results we have to actually run the tests. + No other code is necessary - we can just open the page + with our browser. + </p> + <p> + On failure the display looks like this... + <div class="demo"> + <h1>TestOfLogging</h1> + <span class="fail">Fail</span>: testLogCreatesNewFileOnFirstMessage->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<strong> +class Log { + function Log($file_path) { + } + + function message() { + } +}</strong> +?> +</pre> + It's fun to write the code after the test. + More than fun even - + this system is called "Test Driven Development". + </p> + <p> + For more information about <span class="new_code">UnitTestCase</span>, see + the <a href="unit_test_documentation.html">unit test documentation</a>. + </p> + + <h2> +<a class="target" name="group"></a>Building test suites</h2> + <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 for the application. + </p> + <p> + Our first step is to create a new file called <em>tests/all_tests.php</em> + and insert the following code... +<pre> +<?php +<strong>require_once('simpletest/autorun.php');</strong> + +class AllTests extends <strong>TestSuite</strong> { + function AllTests() { + $this->TestSuite(<strong>'All tests'</strong>); + <strong>$this->addFile('log_test.php');</strong> + } +} +?> +</pre> + The "autorun" include allows our upcoming test suite + to be run just by invoking this script. + </p> + <p> + The <span class="new_code">TestSuite</span> subclass must chain it's constructor. + This limitation will be removed in future versions. + </p> + <p> + The method <span class="new_code">TestSuite::addFile()</span> + will include the test case file and read any new classes + that are descended from <span class="new_code">SimpleTestCase</span>. + <span class="new_code">UnitTestCase</span> is just one example of a class derived from + <span class="new_code">SimpleTestCase</span>, and you can create your own. + <span class="new_code">TestSuite::addFile()</span> can include other test suites. + </p> + <p> + The class will not be instantiated yet. + When the test suite runs it will construct each instance once + it reaches that test, then destroy it straight after. + This means that the constructor is run just before each run + of that test case, and the destructor is run before the next test case starts. + </p> + <p> + It is common to group test case code into superclasses which are not + supposed to run, but become the base classes of other tests. + For "autorun" to work properly the test case file should not blindly run + 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 mark your + base class as <span class="new_code">abstract</span>. + SimpleTest won't run abstract classes. + If you are still using PHP4, then + a <span class="new_code">SimpleTestOptions::ignore()</span> directive + somewhere in the test case file will have the same effect. + </p> + <p> + 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">TestSuite::addFile()</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 or the command line. + </p> + <p> + For more information about building test suites, + see the <a href="group_test_documentation.html">test suite documentation</a>. + </p> + + <h2> +<a class="target" name="mock"></a>Using mock objects</h2> + <p> + Let's move further into the future and do something really complicated. + </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> +<?php +require_once('simpletest/autorun.php'); +require_once('../classes/log.php'); +<strong>require_once('../classes/session_pool.php');</strong> + +class <strong>TestOfSessionLogging</strong> extends UnitTestCase { + + function setUp() { + <strong>@unlink('/temp/test.log');</strong> + } + + function tearDown() { + <strong>@unlink('/temp/test.log');</strong> + } + + function testLoggingInIsLogged() { + <strong>$log = new Log('/temp/test.log'); + $session_pool = &new SessionPool($log); + $session_pool->logIn('fred');</strong> + $messages = file('/temp/test.log'); + $this->assertEqual($messages[0], "User fred logged in.<strong>\n</strong>"); + } +} +?> +</pre> + We'll explain the <span class="new_code">setUp()</span> and <span class="new_code">tearDown()</span> + methods later. + </p> + <p> + 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. + 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? + It means that our <span class="new_code">TestOfSessionLogging</span> test will + fail, even thouh it's not testing Logging. + </p> + <p> + It's fragile in smaller ways too. + 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 can reduce coupling if we 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? + We can create such an object easily... +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('../classes/log.php'); +require_once('../classes/session_pool.php'); + +<strong>Mock::generate('Log');</strong> + +class TestOfSessionLogging extends UnitTestCase { + + function testLoggingInIsLogged() {<strong> + $log = &new MockLog(); + $log->expectOnce('message', array('User fred logged in.'));</strong> + $session_pool = &new SessionPool(<strong>$log</strong>); + $session_pool->logIn('fred'); + } +} +?> +</pre> + The <span class="new_code">Mock::generate()</span> call code generated a new class + called <span class="new_code">MockLog</span>. + This looks like an identical clone, except that we can wire test code + to it. + That's what <span class="new_code">expectOnce()</span> does. + It says that if <span class="new_code">message()</span> is ever called on me, it had + better be with the parameter "User fred logged in.". + </p> + <p> + 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 by <span class="new_code">SessionPool::logIn()</span> code. + 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 you don't have to test every parameter of + a call when you only want to test one. + </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 more information about mocking and stubbing, see the + <a href="mock_objects_documentation.html">mock objects documentation</a>. + </p> + + <h2> +<a class="target" name="web"></a>Web page testing</h2> + <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, as there is + no JavaScript. + Most other browser operations are simulated. + </p> + <p> + 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 +require_once('simpletest/autorun.php'); +<strong>require_once('simpletest/web_tester.php');</strong> + +class TestOfAbout extends <strong>WebTestCase</strong> { + function testOurAboutPageGivesFreeReignToOurEgo() { + <strong>$this->get('http://test-server/index.php'); + $this->click('About'); + $this->assertTitle('About why we are so great'); + $this->assertText('We are really great');</strong> + } +} +?> +</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> + You can navigate forms too... +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('simpletest/web_tester.php'); + +class TestOfRankings extends WebTestCase { + function testWeAreTopOfGoogle() { + $this->get('http://google.com/'); + $this->setField('q', 'simpletest'); + $this->click("I'm Feeling Lucky"); + $this->assertTitle('SimpleTest - Unit Testing for PHP'); + } +} +?> +</pre> + ...although this could violate Google's(tm) terms and conditions. + </p> + <p> + For more information about web testing, see the + <a href="browser_documentation.html">scriptable + browser documentation</a> and the + <a href="web_tester_documentation.html">WebTestCase</a>. + </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> + References and related information... + <ul> +<li> + <a href="https://sourceforge.net/project/showfiles.php?group_id=76550&release_id=153280">Download PHP SimpleTest</a> + from <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + The <a href="http://simpletest.org/api/">developer's API for SimpleTest</a> + gives full detail on the classes and assertions available. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<span class="chosen">SimpleTest</span> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/mock_objects_documentation.html b/3rdparty/simpletest/docs/en/mock_objects_documentation.html new file mode 100644 index 00000000000..b4697f9ee3b --- /dev/null +++ b/3rdparty/simpletest/docs/en/mock_objects_documentation.html @@ -0,0 +1,870 @@ +<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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <span class="chosen">Mock objects</span> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Mock objects documentation</h1> + This page... + <ul> +<li> + <a href="#what">What are mock objects?</a> + </li> +<li> + <a href="#creation">Creating mock objects</a>. + </li> +<li> + <a href="#expectations">Mocks as critics</a> with expectations. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="what"></a>What are mock objects?</h2> + <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 (<a href="">Testing + object-oriented systems</a>: 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> + + <h2> +<a class="target" name="creation"></a>Creating mock objects</h2> + <p> + All we need is an existing class or interface, say a database connection + that looks like this... +<pre> +<strong>class DatabaseConnection { + function DatabaseConnection() { } + function query($sql) { } + function selectQuery($sql) { } +}</strong> +</pre> + To create a mock version of the class we need to run a + code generator... +<pre> +require_once('simpletest/autorun.php'); +require_once('database_connection.php'); + +<strong>Mock::generate('DatabaseConnection');</strong> +</pre> + This code generates a clone class called + <span class="new_code">MockDatabaseConnection</span>. + This new class appears to be the same, but actually has no behaviour at all. + </p> + <p> + The new class is usually a subclass of <span class="new_code">DatabaseConnection</span>. + Unfortunately, there is no way to create a mock version of a + class with a <span class="new_code">final</span> method without having a living version of + that method. + We consider that unsafe. + If the target is an interface, or if <span class="new_code">final</span> methods are + present in a target class, then a whole new class + is created, but one implemeting the same interfaces. + If you try to pass this separate class through a type hint that specifies + the old concrete class name, it will fail. + Code like that insists on type hinting to a class with <span class="new_code">final</span> + methods probably cannot be safely tested with mocks. + </p> + <p> + If you want to see the generated code, then simply <span class="new_code">print</span> + the output of <span class="new_code">Mock::generate()</span>. + Here is the generated code for the <span class="new_code">DatabaseConnection</span> + class rather than the interface version... +<pre> +class MockDatabaseConnection extends DatabaseConnection { + public $mock; + protected $mocked_methods = array('databaseconnection', 'query', 'selectquery'); + + function MockDatabaseConnection() { + $this->mock = new SimpleMock(); + $this->mock->disableExpectationNameChecks(); + } + ... + function DatabaseConnection() { + $args = func_get_args(); + $result = &$this->mock->invoke("DatabaseConnection", $args); + return $result; + } + function query($sql) { + $args = func_get_args(); + $result = &$this->mock->invoke("query", $args); + return $result; + } + function selectQuery($sql) { + $args = func_get_args(); + $result = &$this->mock->invoke("selectQuery", $args); + return $result; + } +} +</pre> + Your output may vary depending on the exact version + of SimpleTest you are using. + </p> + <p> + Besides the original methods of the class, you will see some extra + methods that help testing. + More on these later. + </p> + <p> + We can now create instances of the new class within + our test case... +<pre> +require_once('simpletest/autorun.php'); +require_once('database_connection.php'); + +Mock::generate('DatabaseConnection'); + +class MyTestCase extends UnitTestCase { + + function testSomething() { + <strong>$connection = new MockDatabaseConnection();</strong> + } +} +</pre> + The mock version now has all the methods of the original. + Also, any type hints will be faithfully preserved. + Say our query methods expect a <span class="new_code">Query</span> object... +<pre> +<strong>class DatabaseConnection { + function DatabaseConnection() { } + function query(Query $query) { } + function selectQuery(Query $query) { } +}</strong> +</pre> + If we now pass the wrong type of object, or worse a non-object... +<pre> +class MyTestCase extends UnitTestCase { + + function testSomething() { + $connection = new MockDatabaseConnection(); + $connection->query('insert into accounts () values ()'); + } +} +</pre> + ...the code will throw a type violation at you just as the + original class would. + </p> + <p> + The mock version now has all the methods of the original. + Unfortunately, they all return <span class="new_code">null</span>. + As methods that always return <span class="new_code">null</span> are not that useful, + we need to be able to set them to something else... + </p> + <p> + <a class="target" name="stub"><h2>Mocks as actors</h2></a> + </p> + <p> + Changing the return value of a method from <span class="new_code">null</span> + to something else is pretty easy... +<pre> +<strong>$connection->returns('query', 37)</strong> +</pre> + Now every time we call + <span class="new_code">$connection->query()</span> we get + the result of 37. + There is nothing special about 37. + The return value can be arbitrarily complicated. + </p> + <p> + 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> + 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->returns('next', false); + $iterator->returnsAt(0, 'next', 'First string'); + $iterator->returnsAt(1, 'next', 'Second string');</strong> + ... + } +} +</pre> + When <span class="new_code">next()</span> is called on the + <span class="new_code">MockIterator</span> 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 get($key) { ... } +} +</pre> + This is a likely situation for using mock objects, as + actual configuration will vary from machine to machine and + even from test to test. + The problem though is that all the data comes through the + <span class="new_code">get()</span> method and yet + we want different results for different keys. + Luckily the mocks have a filter system... +<pre> +<strong>$config = &new MockConfiguration(); +$config->returns('get', 'primary', array('db_host')); +$config->returns('get', 'admin', array('db_user')); +$config->returns('get', '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">get()</span> method invoked + like this... +<pre> +$config->get('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->returns('get', false, array('*'));</strong> +</pre> + This is not the same as setting the return value without + any argument requirements like this... +<pre><strong> +$config->returns('get', 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 reference to be + dished out by the mock rather than a copy or object handle. + This a rarity to say the least, but you might be simulating + a container that can hold primitives such as strings. + For example... +<pre> +class Pad { + function Pad() { } + function &note($index) { } +} +</pre> + In this case you can set a reference into the mock's + return list... +<pre> +function testTaskReads() { + $note = 'Buy books'; + $pad = new MockPad(); + $vector-><strong>returnsByReference(</strong>'note', $note, array(3)<strong>)</strong>; + $task = new Task($pad); + ... +} +</pre> + With this arrangement you know that every time + <span class="new_code">$pad->note(3)</span> is + called it will return the same <span class="new_code">$note</span> each time, + even if it get's modified. + </p> + <p> + These three factors, timing, parameters and whether to copy, + can be combined orthogonally. + For example... +<pre> +$buy_books = 'Buy books'; +$write_code = 'Write code'; +$pad = new MockPad(); +$vector-><strong>returnsByReferenceAt(0, 'note', $buy_books, array('*', 3));</strong> +$vector-><strong>returnsByReferenceAt(1, 'note', $write_code, array('*', 3));</strong> +</pre> + This will return a reference to <span class="new_code">$buy_books</span> and + then to <span class="new_code">$write_code</span>, but only if two parameters + were set the second of which must be the integer 3. + That should cover most 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 the the iterator's <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... +<pre> +Mock::generate('DatabaseConnection'); +Mock::generate('ResultIterator'); + +class DatabaseTest extends UnitTestCase { + + function testUserFinderReadsResultsFromDatabase() {<strong> + $result = new MockResultIterator(); + $result->returns('next', false); + $result->returnsAt(0, 'next', array(1, 'tom')); + $result->returnsAt(1, 'next', array(3, 'dick')); + $result->returnsAt(2, 'next', array(6, 'harry')); + + $connection = new MockDatabaseConnection(); + $connection->returns('selectQuery', $result);</strong> + + $finder = new UserFinder(<strong>$connection</strong>); + $this->assertIdentical( + $finder->findNames(), + array('tom', 'dick', 'harry')); + } +} +</pre> + Now only if our + <span class="new_code">$connection</span> is called with the + <span class="new_code">query()</span> method 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> + We could refine this test further by insisting that the correct + query is sent... +<pre> +$connection->returns('selectQuery', $result, array(<strong>'select name, id from people'</strong>)); +</pre> + This is actually a bad idea. + </p> + <p> + We have a <span class="new_code">UserFinder</span> in object land, talking to + database tables using a large interface - the whole of SQL. + Imagine that we have written a lot of tests that now depend + on the exact SQL string passed. + These queries could change en masse for all sorts of reasons + not related to the specific test. + For example the quoting rules could change, a table name could + change, a link table added or whatever. + This would require the rewriting of every single test any time + one of these refactoring is made, yet the intended behaviour has + stayed the same. + Tests are supposed to help refactoring, not hinder it. + I'd certainly like to have a test suite that passes while I change + table names. + </p> + <p> + As a rule it is best not to mock a fat interface. + </p> + <p> + By contrast, here is the round trip test... +<pre> +class DatabaseTest extends UnitTestCase {<strong> + function setUp() { ... } + function tearDown() { ... }</strong> + + function testUserFinderReadsResultsFromDatabase() { + $finder = new UserFinder(<strong>new DatabaseConnection()</strong>); + $finder->add('tom'); + $finder->add('dick'); + $finder->add('harry'); + $this->assertIdentical( + $finder->findNames(), + array('tom', 'dick', 'harry')); + } +} +</pre> + This test is immune to schema changes. + It will only fail if you actually break the functionality, which + is what you want a test to do. + </p> + <p> + The catch is those <span class="new_code">setUp()</span> and <span class="new_code">tearDown()</span> + methods that we've rather glossed over. + They have to clear out the database tables and ensure that the + schema is defined correctly. + That can be a chunk of extra work, but you usually have this code + lying around anyway for deployment purposes. + </p> + <p> + One place where you definitely need a mock is simulating failures. + Say the database goes down while <span class="new_code">UserFinder</span> is doing + it's work. + Does <span class="new_code">UserFinder</span> behave well...? +<pre> +class DatabaseTest extends UnitTestCase { + + function testUserFinder() { + $connection = new MockDatabaseConnection();<strong> + $connection->throwOn('selectQuery', new TimedOut('Ouch!'));</strong> + $alert = new MockAlerts();<strong> + $alert->expectOnce('notify', 'Database is busy - please retry');</strong> + $finder = new UserFinder($connection, $alert); + $this->assertIdentical($finder->findNames(), array()); + } +} +</pre> + We've passed the <span class="new_code">UserFinder</span> an <span class="new_code">$alert</span> + object. + This is going to do some kind of pretty notifications in the + user interface in the event of an error. + We'd rather not sprinkle our code with hard wired <span class="new_code">print</span> + statements if we can avoid it. + Wrapping the means of output means we can use this code anywhere. + It also makes testing easier. + </p> + <p> + To pass this test, the finder has to write a nice user friendly + message to <span class="new_code">$alert</span>, rather than propogating the exception. + So far, so good. + </p> + <p> + How do we get the mock <span class="new_code">DatabaseConnection</span> to throw an exception? + We generate the exception using the <span class="new_code">throwOn</span> method + on the mock. + </p> + <p> + Finally, what if the method you want to simulate does not exist yet? + If you set a return value on a method that is not there, SimpleTest + will throw an error. + What if you are using <span class="new_code">__call()</span> to simulate dynamic methods? + </p> + <p> + Objects with dynamic interfaces, using <span class="new_code">__call</span>, can + be problematic with the current mock objects implementation. + You can mock the <span class="new_code">__call()</span> method, but this is ugly. + Why should a test know anything about such low level implementation details? + It just wants to simulate the call. + </p> + <p> + The way round this is to add extra methods to the mock when + generating it. +<pre> +<strong>Mock::generate('DatabaseConnection', 'MockDatabaseConnection', array('setOptions'));</strong> +</pre> + In a large test suite this could cause trouble, as you probably + already have a mock version of the class called + <span class="new_code">MockDatabaseConnection</span> without the extra methods. + The code generator will not generate a mock version of the class if + one of the same name already exists. + You will confusingly fail to see your method if another definition + was run first. + </p> + <p> + To cope with this, SimpleTest allows you to choose any name for the + new class at the same time as you add the extra methods. +<pre> +Mock::generate('DatabaseConnection', <strong>'MockDatabaseConnectionWithOptions'</strong>, array('setOptions')); +</pre> + Here the mock will behave as if the <span class="new_code">setOptions()</span> + existed in the original class. + </p> + <p> + Mock objects can only be used within test cases, as upon expectations + they send messages straight to the currently running test case. + Creating them outside a test case will cause a run time error + when an expectation is triggered and there is no running test case + for the message to end up. + We cover expectations next. + </p> + + <h2> +<a class="target" name="expectations"></a>Mocks as critics</h2> + <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, let's take a simple <span class="new_code">PageController</span> + class to handle a credit card payment form... +<pre> +class PaymentForm extends PageController { + function __construct($alert, $payment_gateway) { ... } + function makePayment($request) { ... } +} +</pre> + This class takes a <span class="new_code">PaymentGateway</span> to actually talk + to the bank. + It also takes an <span class="new_code">Alert</span> object to handle errors. + This class talks to the page or template. + It's responsible for painting the error message and highlighting any + form fields that are incorrect. + </p> + <p> + It might look something like... +<pre> +class Alert { + function warn($warning, $id) { + print '<div class="warning">' . $warning . '</div>'; + print '<style type="text/css">#' . $id . ' { background-color: red }</style>'; + } +} +</pre> + </p> + <p> + Our interest is in the <span class="new_code">makePayment()</span> method. + If we fail to enter a "CVV2" number (the three digit number + on the back of the credit card), we want to show an error rather than + try to process the payment. + In test form... +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('payment_form.php'); +Mock::generate('Alert'); +Mock::generate('PaymentGateway'); + +class PaymentFormFailuresShouldBeGraceful extends UnitTestCase { + + function testMissingCvv2CausesAlert() { + $alert = new MockAlert(); + <strong>$alert->expectOnce( + 'warn', + array('Missing three digit security code', 'cvv2'));</strong> + $controller = new PaymentForm(<strong>$alert</strong>, new MockPaymentGateway()); + $controller->makePayment($this->requestWithMissingCvv2()); + } + + function requestWithMissingCvv2() { ... } +} +?> +</pre> + The first question you may be asking is, where are the assertions? + </p> + <p> + The call to <span class="new_code">expectOnce('warn', array(...))</span> instructs the mock + to expect a call to <span class="new_code">warn()</span> before the test ends. + When it gets a call to <span class="new_code">warn()</span>, it checks the arguments. + If the arguments don't match, then a failure is generated. + It also fails if the method is never called at all. + </p> + <p> + The test above not only asserts that <span class="new_code">warn</span> was called, + but that it received the string "Missing three digit security code" + and also the tag "cvv2". + The equivalent of <span class="new_code">assertIdentical()</span> is applied to both + fields when the parameters are compared. + </p> + <p> + If you are not interested in the actual message, and we are not + for user interface code that changes often, we can skip that + parameter with the "*" operator... +<pre> +class PaymentFormFailuresShouldBeGraceful extends UnitTestCase { + + function testMissingCvv2CausesAlert() { + $alert = new MockAlert(); + $alert->expectOnce('warn', array(<strong>'*'</strong>, 'cvv2')); + $controller = new PaymentForm($alert, new MockPaymentGateway()); + $controller->makePayment($this->requestWithMissingCvv2()); + } + + function requestWithMissingCvv2() { ... } +} +</pre> + We can weaken the test further by missing + out the parameters array... +<pre> +function testMissingCvv2CausesAlert() { + $alert = new MockAlert(); + <strong>$alert->expectOnce('warn');</strong> + $controller = new PaymentForm($alert, new MockPaymentGateway()); + $controller->makePayment($this->requestWithMissingCvv2()); +} +</pre> + This will only test that the method is called, + which is a bit drastic in this case. + Later on, we'll see how we can weaken the expectations more precisely. + </p> + <p> + Tests without assertions can be both compact and very expressive. + Because we intercept the call on the way into an object, here of + the <span class="new_code">Alert</span> class, we avoid having to assert its state + afterwards. + This not only avoids the assertions in the tests, but also having + to add extra test only accessors to the original code. + If you catch yourself adding such accessors, called "state based testing", + it's probably time to consider using mocks in the tests. + This is called "behaviour based testing", and is normally superior. + </p> + <p> + Let's add another test. + Let's make sure that we don't even attempt a payment without a CVV2... +<pre> +class PaymentFormFailuresShouldBeGraceful extends UnitTestCase { + + function testMissingCvv2CausesAlert() { ... } + + function testNoPaymentAttemptedWithMissingCvv2() { + $payment_gateway = new MockPaymentGateway(); + <strong>$payment_gateway->expectNever('pay');</strong> + $controller = new PaymentForm(new MockAlert(), $payment_gateway); + $controller->makePayment($this->requestWithMissingCvv2()); + } + + ... +} +</pre> + Asserting a negative can be very hard in tests, but + <span class="new_code">expectNever()</span> makes it easy. + </p> + <p> + <span class="new_code">expectOnce()</span> and <span class="new_code">expectNever()</span> are + sufficient for most tests, but + occasionally you want to test multiple events. + Normally for usability purposes we want all missing fields + in the form to light up, not just the first one. + This means that we should get multiple calls to + <span class="new_code">Alert::warn()</span>, not just one... +<pre> +function testAllRequiredFieldsHighlightedOnEmptyRequest() { + $alert = new MockAlert();<strong> + $alert->expectAt(0, 'warn', array('*', 'cc_number')); + $alert->expectAt(1, 'warn', array('*', 'expiry')); + $alert->expectAt(2, 'warn', array('*', 'cvv2')); + $alert->expectAt(3, 'warn', array('*', 'card_holder')); + $alert->expectAt(4, 'warn', array('*', 'address')); + $alert->expectAt(5, 'warn', array('*', 'postcode')); + $alert->expectAt(6, 'warn', array('*', 'country')); + $alert->expectCallCount('warn', 7);</strong> + $controller = new PaymentForm($alert, new MockPaymentGateway()); + $controller->makePayment($this->requestWithMissingCvv2()); +} +</pre> + The counter in <span class="new_code">expectAt()</span> is the number of times + the method has been called already. + Here we are asserting that every field will be highlighted. + </p> + <p> + Note that we are forced to assert the order too. + SimpleTest does not yet have a way to avoid this, but + this will be fixed in future versions. + </p> + <p> + Here is the full list of expectations you can set on a mock object + in <a href="http://simpletest.org/">SimpleTest</a>. + As with the assertions, these methods take an optional failure message. + <table> + <thead><tr> +<th>Expectation</th> +<th>Description</th> +</tr></thead> + <tbody> + <tr> + <td><span class="new_code">expect($method, $args)</span></td> + <td>Arguments must match if called</td> + </tr> + <tr> + <td><span class="new_code">expectAt($timing, $method, $args)</span></td> + <td>Arguments must match when called on the <span class="new_code">$timing</span>'th time</td> + </tr> + <tr> + <td><span class="new_code">expectCallCount($method, $count)</span></td> + <td>The method must be called exactly this many times</td> + </tr> + <tr> + <td><span class="new_code">expectMaximumCallCount($method, $count)</span></td> + <td>Call this method no more than <span class="new_code">$count</span> times</td> + </tr> + <tr> + <td><span class="new_code">expectMinimumCallCount($method, $count)</span></td> + <td>Must be called at least <span class="new_code">$count</span> times</td> + </tr> + <tr> + <td><span class="new_code">expectNever($method)</span></td> + <td>Must never be called</td> + </tr> + <tr> + <td><span class="new_code">expectOnce($method, $args)</span></td> + <td>Must be called once and with the expected arguments if supplied</td> + </tr> + <tr> + <td><span class="new_code">expectAtLeastOnce($method, $args)</span></td> + <td>Must be called at least once, and always with any expected arguments</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 and the count is for + each method independently. + </dd> + <dt class="new_code">$count</dt> + <dd>The number of calls expected.</dd> + </dl> + </p> + <p> + If you have just one call in your test, make sure you're using + <span class="new_code">expectOnce</span>.<br> + Using <span class="new_code">$mocked->expectAt(0, 'method', 'args);</span> + on its own will allow the method to never be called. + Checking the arguments and the overall call count + are currently independant. + Add an <span class="new_code">expectCallCount()</span> expectation when you + are using <span class="new_code">expectAt()</span> unless zero calls is allowed. + </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> + + </div> + References and related information... + <ul> +<li> + The original + <a href="http://www.mockobjects.com/">Mock objects</a> paper. + </li> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest home page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <span class="chosen">Mock objects</span> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/overview.html b/3rdparty/simpletest/docs/en/overview.html new file mode 100644 index 00000000000..85ea9407749 --- /dev/null +++ b/3rdparty/simpletest/docs/en/overview.html @@ -0,0 +1,487 @@ +<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"> +<a href="index.html">SimpleTest</a> + | + <span class="chosen">Overview</span> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Overview of SimpleTest</h1> + This page... + <ul> +<li> + <a href="#summary">Quick summary</a> + of the SimpleTest tool for PHP. + </li> +<li> + <a href="#features">List of features</a>, + both current ones and those planned. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="summary"></a>What is SimpleTest?</h2> + <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. + Each test method of a test case class 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 + or unexpected exception triggers an alert and a description + of the mismatch. + These test case declarations are transformed into executable + test scripts by including a SimpleTest aurorun.php file. + </p> + <p> + These documents apply to SimpleTest version 1.1, although we + try hard to maintain compatibility between versions. + If you get a test failure after an upgrade, check out the + file "HELP_MY_TESTS_DONT_WORK_ANYMORE" in the + simpletest directory to see if a feature you are using + has since been deprecated and later removed. + </p> + <p> + A <a href="unit_test_documentation.html">test case</a> looks like this... +<pre> +<?php +require_once('simpletest/autorun.php'); + +class <strong>CanAddUp</strong> extends UnitTestCase {<strong> + function testOneAndOneMakesTwo() { + $this->assertEqual(1 + 1, 2); + }</strong> +} +?> +</pre> + Tests are grouped into test cases, which are just + PHP classes that extend <span class="new_code">UnitTestCase</span> + or <span class="new_code">WebTestCase</span>. + The tests themselves are just normal methods that start + their name with the letters "test". + You can have as many test cases as you want in a test + script and each test case can have as many test methods + as it wants too. + </p> + <p> + This test script is immediately runnable. + You just invoke it on the command line like so... +<pre class="shell"> +php adding_test.php +</pre> + </p> + <p> + When run on the command line you should see something like... +<pre class="shell"> +adding_test.php +OK +Test cases run: 1/1, Passes: 1, Failures: 0, Exceptions: 0 +</pre> + </p> + <p> + If you place it on a web server and point your + web browser at it... + <div class="demo"> + <h1>adding_test.php</h1> + <div style="padding: 8px; margin-top: 1em; background-color: green; color: white;">1/1 test cases complete. + <strong>6</strong> passes, <strong>0</strong> fails and <strong>0</strong> exceptions.</div> + </div> + </p> + <p> + Of course this is a silly example. + A more realistic example might be... +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('log.php'); + +class <strong>TestOfLogging</strong> extends UnitTestCase { + function testWillCreateLogFileOnFirstMessage() { + $log = new Log('my.log'); + $this->assertFalse(file_exists('my.log')); + $log->message('Hello'); + $this->assertTrue(file_exists('my.log')); + }</strong> +} +?> +</pre> + </p> + <p> + This tool is designed for the developer. + The target audience of this tool is anyone developing a small + to medium PHP application, including developers new to + unit and web regression testing. + The core principles are ease of use first, with extendibility and + essential features. + </p> + <p> + Tests are written in the PHP language itself more or less + as the application itself is built. + The advantage of using PHP 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 when they are in the same programming 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 +require_once('simpletest/autorun.php'); +require_once('simpletest/web_tester.php'); + +class <strong>MySiteTest</strong> extends WebTestCase { + <strong> + function testHomePageHasContactDetailsLink() { + $this->get('http://www.my-site.com/index.php'); + $this->assertTitle('My Home Page'); + $this->clickLink('Contact'); + $this->assertTitle('Contact me'); + $this->assertText('/Email me at/'); + }</strong> +} +?> +</pre> + </p> + + <h2> +<a class="target" name="features"></a>Feature list</h2> + <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. + </p> + <p> + 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 SVN 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>Testing exceptions</td> + <td>Similar to testing PHP errors</td> + <td style="color: green;">1.0.1</td> + </tr> + <tr> + <td>HTML label support</td> + <td>Can access all controls using the visual label</td> + <td style="color: green;">1.0.1</td> + </tr> + <tr> + <td>Base tag support</td> + <td>Respects page base tag when clicking</td> + <td style="color: green;">1.0.1</td> + </tr> + <tr> + <td>PHP 5 E_STRICT compliant</td> + <td>PHP 5 only version that works with the E_STRICT error level</td> + <td style="color: green;">1.1</td> + </tr> + <tr> + <td>Alternate HTML parsers</td> + <td>Can detect compiled parsers for performance improvements</td> + <td style="color: green;">1.1</td> + </tr> + <tr> + <td>REST support</td> + <td>Support for REST verbs as put(), delete(), etc.</td> + <td style="color: green;">1.1</td> + </tr> + <tr> + <td>BDD style fixtures</td> + <td>Can import fixtures using a mixin like given() method</td> + <td style="color: red;">1.5</td> + </tr> + <tr> + <td>Plug-in architecture</td> + <td>Automatic import of extensions including command line options</td> + <td style="color: red;">1.5</td> + </tr> + <tr> + <td>Reporting machinery enhancements</td> + <td>Improved message passing for better cooperation with IDEs</td> + <td style="color: red;">1.5</td> + </tr> + <tr> + <td>Fluent mock interface</td> + <td>More flexible and concise mock objects</td> + <td style="color: red;">1.6</td> + </tr> + <tr> + <td>Localisation</td> + <td>Messages abstracted and code generated as well as UTF support</td> + <td style="color: red;">1.6</td> + </tr> + <tr> + <td>CSS selectors</td> + <td>HTML content can be examined using CSS selectors</td> + <td style="color: red;">1.7</td> + </tr> + <tr> + <td>HTML table assertions</td> + <td>Can match HTML or other table elements to expectations</td> + <td style="color: red;">1.7</td> + </tr> + <tr> + <td>Unified acceptance testing model</td> + <td>Content searchable through selectors combined with expectations</td> + <td style="color: red;">1.7</td> + </tr> + <tr> + <td>DatabaseTestCase</td> + <td>SQL selectors and DB drivers</td> + <td style="color: red;">1.7</td> + </tr> + <tr> + <td>IFrame support</td> + <td>Reads IFrame content that can be refreshed</td> + <td style="color: red;">1.8</td> + </tr> + <tr> + <td>Integrated Selenium support</td> + <td>Easy to use built in Selenium driver and tutorial or similar browser automation</td> + <td style="color: red;">1.9</td> + </tr> + <tr> + <td>Code coverage</td> + <td>Reports using the bundled tool when using XDebug</td> + <td style="color: red;">1.9</td> + </tr> + <tr> + <td>Deprecation of old methods</td> + <td>Simpler interface for SimpleTest2</td> + <td style="color: red;">2.0</td> + </tr> + <tr> + <td>Javascript suport</td> + <td>Use of PECL module to add Javascript to the native browser</td> + <td style="color: red;">3.0</td> + </tr> + </tbody> +</table> + PHP 5 migration is complete, which means that only PHP 5.0.3+ + will be supported in SimpleTest version 1.1+. + Earlier versions of SimpleTest are compatible with PHP 4.2 up to + PHP 5 (non E_STRICT). + </p> + + </div> + References and related information... + <ul> +<li> + <a href="unit_test_documentation.html">Documentation for SimpleTest</a>. + </li> +<li> + <a href="http://www.lastcraft.com/first_test_tutorial.php">How to write PHP test cases</a> + is a fairly advanced tutorial. + </li> +<li> + <a href="http://simpletest.org/api/">SimpleTest API</a> from phpdoc. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <span class="chosen">Overview</span> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/partial_mocks_documentation.html b/3rdparty/simpletest/docs/en/partial_mocks_documentation.html new file mode 100644 index 00000000000..cb70b1f86df --- /dev/null +++ b/3rdparty/simpletest/docs/en/partial_mocks_documentation.html @@ -0,0 +1,457 @@ +<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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <span class="chosen">Partial mocks</span> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Partial mock objects documentation</h1> + This page... + <ul> +<li> + <a href="#inject">The mock injection problem</a>. + </li> +<li> + Moving creation to a <a href="#creation">protected factory</a> method. + </li> +<li> + <a href="#partial">Partial mocks</a> generate subclasses. + </li> +<li> + Partial mocks <a href="#less">test less than a class</a>. + </li> +</ul> +<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> + + <h2> +<a class="target" name="inject"></a>The mock injection problem</h2> + <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(); + ... + $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(); + ... + $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(); + ... + $network = new MockNetwork(); + $network->returnsByReference('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> + Well techniques like "Dependency Injection" tackle the problem of + instantiating a lot of constructor parameters. + Unfortunately knowledge of this pattern is not widespread, and if you + are trying to get older code to work, rearchitecting the whole + application is not really an option. + </p> + <p> + Is there a middle ground? + </p> + + <h2> +<a class="target" name="creation"></a>Protected factory method</h2> + <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> + + protected function createSocket($ip, $port) { + return new Socket($ip, $port); + }</strong> +} +?> +</pre> + This is a pretty safe step even for very tangled legacy code. + This is the only change we make to the application. + </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(); + } + + protected 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(); + ... + $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> + + <h2> +<a class="target" name="partial"></a>A partial mock</h2> + <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(); + ... + $telnet = new TelnetTestVersion(); + $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(); + ... + $telnet = new TelnetTestVersion(); + $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'); + } +} +</pre> + Partial mocks are not used often. + I consider them transitory. + Useful while refactoring, but once the application has + all of it's dependencies nicely separated then the + partial mocks can wither away. + </p> + + <h2> +<a class="target" name="less"></a>Testing less than a class</h2> + <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've hardly + tried it. + I am 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 if you allow test mechanisms like this. + </p> + + </div> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + <a href="http://simpletest.org/api/">Full API for SimpleTest</a> + from the PHPDoc. + </li> +<li> + The protected factory is described in + <a href="http://www-106.ibm.com/developerworks/java/library/j-mocktest.html">this paper from IBM</a>. + This is the only formal comment I have seen on this problem. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <span class="chosen">Partial mocks</span> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/reporter_documentation.html b/3rdparty/simpletest/docs/en/reporter_documentation.html new file mode 100644 index 00000000000..8924b7bb67a --- /dev/null +++ b/3rdparty/simpletest/docs/en/reporter_documentation.html @@ -0,0 +1,616 @@ +<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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <span class="chosen">Reporting</span> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Test reporter documentation</h1> + This page... + <ul> +<li> + Displaying <a href="#html">results in HTML</a> + </li> +<li> + Displaying and <a href="#other">reporting results</a> + in other formats + </li> +<li> + Using <a href="#cli">SimpleTest from the command line</a> + </li> +<li> + <a href="#xml">Using XML</a> for remote testing + </li> +</ul> +<div class="content"> + + <p> + SimpleTest pretty much follows the MVC-ish 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> + + <h2> +<a class="target" name="html"></a>Reporting results in HTML</h2> + <p> + The default HTML 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 __construct($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 title, 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, top level test case, 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 ReporterShowingPasses 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"; + } + + protected 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> + + <h2> +<a class="target" name="other"></a>Extending the reporter</h2> + <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/simpletest.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> + } + + function paintError($message) {<strong> + parent::paintError($message);</strong> + } + + function paintException($exception) {<strong> + parent::paintException($exception);</strong> + } +} +</pre> + No output would come from this class until you add it. + </p> + <p> + The catch with using this low level class is that you must + explicitely invoke it in the test script. + The "autorun" facility will not be able to use + its runtime context (whether it's running in a web browser + or the command line) to select the reporter. + </p> + <p> + You explicitely invoke the test runner like so... +<pre> +<?php +require_once('simpletest/autorun.php'); + +$test = new TestSuite('File test'); +$test->addFile('tests/file_test.php'); +$test->run(<strong>new MyReporter()</strong>); +?> +</pre> + ...perhaps like this... +<pre> +<?php +require_once('simpletest/simpletest.php'); +require_once('my_reporter.php'); + +class MyTest extends TestSuite { + function __construct() { + parent::__construct(); + $this->addFile('tests/file_test.php'); + } +} + +$test = new MyTest(); +$test->run(<strong>new MyReporter()</strong>); +?> +</pre> + We'll show how to fit in with "autorun" later. + </p> + + <h2> +<a class="target" name="cli"></a>The command line reporter</h2> + <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 explicitely, substitute it + for the HTML version... +<pre> +<?php +require_once('simpletest/autorun.php'); + +$test = new TestSuite('File test'); +$test->addFile('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, Passes: 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, Passes: 0, 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/autorun.php'); + +$test = new TestSuite('File test'); +$test->addFile('tests/file_test.php'); +<strong>exit ($test->run(new TextReporter()) ? 0 : 1);</strong> +?> +</pre> + Of course we wouldn'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/autorun.php'); + +$test = new TestSuite('File test'); +$test->addFile('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. + When you use the "autorun.php", and no + test has been run by the end, this is pretty much + the code that SimpleTest will run for you implicitely. + </p> + <p> + In other words, this is gives the same result... +<pre> +<?php +require_once('simpletest/autorun.php'); + +class MyTest extends TestSuite { + function __construct() { + parent::__construct(); + $this->addFile('tests/file_test.php'); + } +} +?> +</pre> + </p> + + <h2> +<a class="target" name="xml"></a>Remote testing</h2> + <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> + To get your normal test cases to produce this format, on the + command line add the <span class="new_code">--xml</span> flag. +<pre class="shell"> +php my_test.php --xml +</pre> + You can do teh same thing in the web browser by adding the + URL parameter <span class="new_code">xml=1</span>. + Any true value will do. + </p> + <p> + You can consume 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> + Most likely it's when you want to isolate a problematic crash + prone test. + You can collect the XML output using the backtick operator + from another test. + In that way it runs in its own process... +<pre> +<?php +require_once('simpletest/xml.php'); + +if (TextReporter::inCli()) { + $parser = new SimpleTestXmlParser(new TextReporter()); +} else { + $parser = new SimpleTestXmlParser(new HtmlReporter()); +} +$parser->parse(`php flakey_test.php --xml`); +?> +</pre> + </p> + <p> + Another use is breaking up large test suites. + </p> + <p> + A problem with large test suites is thet they can exhaust + the default 16Mb 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('simpletest/autorun.php'); + +$test_url = ...; +$dry_url = ...; + +class MyTestOnAnotherServer extends RemoteTestCase { + function __construct() { + $test_url = ... + parent::__construct($test_url, $test_url . ' --dry'); + } +} +?> +</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 test suite. + </p> + + </div> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest download page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + The <a href="http://simpletest.org/api/">developer's API for SimpleTest</a> + gives full detail on the classes and assertions available. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <span class="chosen">Reporting</span> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/unit_test_documentation.html b/3rdparty/simpletest/docs/en/unit_test_documentation.html new file mode 100644 index 00000000000..a399bf34cb1 --- /dev/null +++ b/3rdparty/simpletest/docs/en/unit_test_documentation.html @@ -0,0 +1,442 @@ +<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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <span class="chosen">Unit tester</span> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>PHP Unit Test documentation</h1> + This page... + <ul> +<li> + <a href="#unit">Unit test cases</a> and basic assertions. + </li> +<li> + <a href="#extending_unit">Extending test cases</a> to + customise them for your own project. + </li> +<li> + <a href="#running_unit">Running a single case</a> as + a single script. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="unit"></a>Unit test cases</h2> + <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> + 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. + </p> + <p> + For example... +<pre> +require_once('simpletest/autorun.php'); +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 interference 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">assertClone($x, $y)</span></td> +<td>Fail unless $x and $y are identical copies</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">expectError($x)</span></td> +<td>Fail if matching error does not occour</td> +</tr> + <tr> +<td><span class="new_code">expectException($x)</span></td> +<td>Fail if matching exception is not thrown</td> +</tr> + <tr> +<td><span class="new_code">ignoreException($x)</span></td> +<td>Swallows any upcoming matching exception</td> +</tr> + <tr> +<td><span class="new_code">assert($e)</span></td> +<td>Fail on failed <a href="expectation_documentation.html">expectation</a> object $e</td> +</tr> + </tbody></table> + All assertion methods can take an optional description as a + last parameter. + This is 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> +$variable = null; +<strong>$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. +<pre> +$a = 1; +$b = $a; +<strong>$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>$this->expectError();</strong> +trigger_error('Catastrophe'); +</pre> + Here the check catches the "Catastrophe" + message without checking the text and passes. + This removes the error from the queue. +<pre> +<strong>$this->expectError('Catastrophe');</strong> +trigger_error('Catastrophe'); +</pre> + The next error check tests not only the existence of the error, + but also the text which, here matches so another pass. + If any unchecked errors are left at the end of a test method then + an exception will be reported in the test. + </p> + <p> + 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">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> + </tbody></table> + </p> + + <h2> +<a class="target" name="extending_unit"></a>Extending test cases</h2> + <p> + Of course additional test methods can be added to create + specific types of test case, so as to extend framework... +<pre> +require_once('simpletest/autorun.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> + To prevent this test case being run accidently, it is + advisable to mark it as <span class="new_code">abstract</span>. + </p> + <p> + Alternatively you could add a + <span class="new_code">SimpleTestOptions::ignore('FileTester');</span> + directive in your code. + </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 a few basics, + 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> + + <h2> +<a class="target" name="running_unit"></a>Running a single test case</h2> + <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. + With <em>autorun</em> no particular scaffolding is needed, + just launch your particular test file and you're ready to go. + </p> + <p> + You can even decide which reporter (for example, + <span class="new_code">TextReporter</span> or <span class="new_code">HtmlReporter</span>) + you prefer for a specific file when launched on its own... +<pre> +<?php +require_once('simpletest/autorun.php');<strong> +SimpleTest :: prefer(new TextReporter());</strong> +require_once('../classes/writer.php'); + +class FileTestCase extends UnitTestCase { + ... +} +?> +</pre> + This script will run as is, but of course will output zero passes + and zero failures until test methods are added. + </p> + + </div> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest download page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + <a href="http://simpletest.org/api/">Full API for SimpleTest</a> + from the PHPDoc. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <span class="chosen">Unit tester</span> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/en/web_tester_documentation.html b/3rdparty/simpletest/docs/en/web_tester_documentation.html new file mode 100644 index 00000000000..aa9df50a679 --- /dev/null +++ b/3rdparty/simpletest/docs/en/web_tester_documentation.html @@ -0,0 +1,588 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>SimpleTest 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"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <span class="chosen">Web tester</span> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Web tester documentation</h1> + This page... + <ul> +<li> + Successfully <a href="#fetch">fetching a web page</a> + </li> +<li> + Testing the <a href="#content">page content</a> + </li> +<li> + <a href="#navigation">Navigating a web site</a> + while testing + </li> +<li> + <a href="#request">Raw request modifications</a> and debugging methods + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="fetch"></a>Fetching a page</h2> + <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 +require_once('simpletest/autorun.php');<strong> +require_once('simpletest/web_tester.php');</strong> +SimpleTest::prefer(new TextReporter()); + +class WebTests extends TestSuite { + function WebTests() { + $this->TestSuite('Web site tests');<strong> + $this->addFile('lastcraft_test.php');</strong> + } +} +?> +</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> + + <h2> +<a class="target" name="content"></a>Testing page content</h2> + <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->assertText('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">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">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">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> + + <h2> +<a class="target" name="navigation"></a>Navigating a web site</h2> + <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> + + <h2> +<a class="target" name="request"></a>Modifying the request</h2> + <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> + References and related information... + <ul> +<li> + SimpleTest project page on <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + SimpleTest download page on <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + The <a href="http://simpletest.org/api/">developer's API for SimpleTest</a> + gives full detail on the classes and assertions available. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <span class="chosen">Web tester</span> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/authentication_documentation.html b/3rdparty/simpletest/docs/fr/authentication_documentation.html new file mode 100644 index 00000000000..fe70e035593 --- /dev/null +++ b/3rdparty/simpletest/docs/fr/authentication_documentation.html @@ -0,0 +1,372 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation Simple Test : tester l'authentification</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur l'authentification</h1> + This page... + <ul> +<li> + Passer au travers d'une <a href="#basique">authentification HTTP basique</a> + </li> +<li> + Tester l'<a href="#cookies">authentification basée sur des cookies</a> + </li> +<li> + Gérer les <a href="#session">sessions du navigateur</a> et les timeouts + </li> +</ul> +<div class="content"> + + <p> + Un des secteurs à la fois délicat et important lors d'un test + de site web reste la sécurité. Tester ces schémas est au coeur + des objectifs du testeur web de SimpleTest. + </p> + + <h2> +<a class="target" name="basique"></a>Authentification HTTP basique</h2> + <p> + Si vous allez chercher une page web protégée + par une authentification basique, vous hériterez d'une entête 401. + Nous pouvons représenter ceci par ce test... +<pre> +class AuthenticationTest extends WebTestCase {<strong> + function test401Header() { + $this->get('http://www.lastcraft.com/protected/'); + $this->showHeaders(); + }</strong> +} +</pre> + Ce qui nous permet de voir les entêtes reçues... + <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> + Sauf que nous voulons éviter l'inspection visuelle, + on souhaite que SimpleTest puisse nous dire si oui ou non + la page est protégée. Voici un test en profondeur sur nos entêtes... +<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> + N'importe laquelle de ces assertions suffirait, + tout dépend de la masse de détails que vous souhaitez voir. + </p> + <p> + Un des axes qui traverse SimpleTest est la possibilité d'utiliser + des objets <span class="new_code">SimpleExpectation</span> à chaque fois qu'une + vérification simple suffit. + Si vous souhaitez vérifiez simplement le contenu du realm - l'identification + du domaine - dans notre exemple, il suffit de faire... +<pre> +class AuthenticationTest extends WebTestCase { + function test401Header() { + $this->get('http://www.lastcraft.com/protected/'); + $this->assertRealm(<strong>new PatternExpectation('/simpletest/i')</strong>); + } +} +</pre> + Ce type de test, vérifier les réponses HTTP, n'est cependant pas commun. + </p> + <p> + La plupart du temps, nous ne souhaitons pas tester + l'authentification en elle-même, mais plutôt + les pages protégées par cette authentification. + Dès que la tentative d'authentification est reçue, + nous pouvons y répondre à l'aide d'une réponse d'authentification : +<pre> +class AuthenticationTest extends WebTestCase { + function testAuthentication() { + $this->get('http://www.lastcraft.com/protected/');<strong> + $this->authenticate('Me', 'Secret');</strong> + $this->assertTitle(...); + } +} +</pre> + Le nom d'utilisateur et le mot de passe seront désormais + envoyés à chaque requête vers ce répertoire + et ses sous-répertoires. + En revanche vous devrez vous authentifier à nouveau + si vous sortez de ce répertoire mais SimpleTest est assez + intelligent pour fusionner les sous-répertoires dans un même domaine. + </p> + <p> + Vous pouvez gagner une ligne en définissant + l'authentification au niveau de l'URL... +<pre> +class AuthenticationTest extends WebTestCase { + function testCanReadAuthenticatedPages() { + $this->get('http://<strong>Me:Secret@</strong>www.lastcraft.com/protected/'); + $this->assertTitle(...); + } +} +</pre> + Si votre nom d'utilisateur ou mot de passe comporte + des caractères spéciaux, alors n'oubliez pas de les encoder, + sinon la requête ne sera pas analysée correctement. + De plus cette entête ne sera pas envoyée aux + sous requêtes si vous la définissez avec une URL absolue. + Par contre si vous naviguez avec des URL relatives, + l'information d'authentification sera préservée. + </p> + <p> + Normalement, vous utilisez l'appel <span class="new_code">authenticate()</span>. SimpleTest + utilisera alors vos informations de connexion à chaque requête. + </p> + <p> + Pour l'instant, seule l'authentification de base est implémentée + et elle n'est réellement fiable qu'en tandem avec une connexion HTTPS. + C'est généralement suffisant pour protéger + le serveur testé des regards malveillants. + Les authentifications Digest et NTLM pourraient être ajoutées prochainement. + </p> + + <h2> +<a class="target" name="cookies"></a>Cookies</h2> + <p> + L'authentification de base ne donne pas assez de contrôle + au développeur Web sur l'interface utilisateur. + Il y a de forte chance pour que cette fonctionnalité + soit codée directement dans l'architecture web + à grand renfort de cookies et de timeouts compliqués. + </p> + <p> + Commençons par un simple formulaire de connexion... +<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> + Lequel doit ressembler à... + </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> + Supposons que, durant le chargement de la page, + un cookie ait été inscrit avec un numéro d'identifiant de session. + Nous n'allons pas encore remplir le formulaire, + juste tester que nous pistons bien l'utilisateur. + Voici le test... +<pre> +class LogInTest extends WebTestCase { + function testSessionCookieSetBeforeForm() { + $this->get('http://www.my-site.com/login.php');<strong> + $this->assertCookie('SID');</strong> + } +} +</pre> + Nous nous contentons ici de vérifier que le cookie a bien été défini. + Etant donné que sa valeur est plutôt énigmatique, + elle ne vaudrait pas la peine d'être testée avec... +<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> + Si vous utilisez PHP pour gérer vos sessions alors + ce test est encore plus inutile, étant donné qu'il ne fait + que tester PHP lui-même. + </p> + <p> + Le test le plus simple pour vérifier que la connexion a bien eu lieu + reste d'inspecter visuellement la page suivante : + un simple appel à <span class="new_code">WebTestCase::assertText()</span> et le tour est joué. + </p> + <p> + Le reste du test est le même que dans n'importe quel autre formulaire, + mais nous pourrions souhaiter nous assurer + que le cookie n'a pas été modifié depuis la phase de connexion. + Voici comment cela pourrait être testé : +<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->clickSubmit('Log in'); + $this->assertWantedPattern('/Welcome Me/'); + $this->assertCookie('SID', $session);</strong> + } +} +</pre> + Ceci confirme que l'identifiant de session + est identique avant et après la connexion. + </p> + <p> + Nous pouvons même essayer de duper notre propre système + en créant un cookie arbitraire pour se connecter... +<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->assertWantedPattern('/Access denied/'); + } +} +</pre> + Votre site est-il protégé contre ce type d'attaque ? + </p> + + <h2> +<a class="target" name="session"></a>Sessions de navigateur</h2> + <p> + Si vous testez un système d'authentification, + la reconnexion par un utilisateur est un point sensible. + Essayons de simuler ce qui se passe dans ce cas : +<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->clickSubmit('Log in'); + $this->assertWantedPattern('/Welcome Me/');<strong> + + $this->restart(); + $this->get('http://www.my-site.com/restricted.php'); + $this->assertWantedPattern('/Access denied/');</strong> + } +} +</pre> + La méthode <span class="new_code">WebTestCase::restart()</span> préserve + les cookies dont le timeout n'a pas expiré, + mais jette les cookies temporaires ou expirés. + Vous pouvez spécifier l'heure et la date de leur réactivation. + </p> + <p> + L'expiration des cookies peut être un problème. + Si vous avez un cookie qui doit expirer au bout d'une heure, + nous n'allons pas mettre le test en veille en attendant + que le cookie expire... + </p> + <p> + Afin de provoquer leur expiration, + vous pouvez dater manuellement les cookies, + avant le début de la 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->clickSubmit('Log in'); + $this->assertWantedPattern('/Welcome Me/'); + <strong> + $this->ageCookies(3600);</strong> + $this->restart(); + $this->get('http://www.my-site.com/restricted.php'); + $this->assertWantedPattern('/Access denied/'); + } +} +</pre> + Après le redémarrage, les cookies seront plus vieux + d'une heure et que tous ceux dont la date d'expiration + sera passée auront disparus. + </p> + + </div> + References and related information... + <ul> +<li> + La page du projet SimpleTest sur <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page de téléchargement de SimpleTest sur <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + <a href="http://simpletest.org/api/">L'API du développeur pour SimpleTest</a> donne tous les détails sur les classes et les assertions disponibles. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/browser_documentation.html b/3rdparty/simpletest/docs/fr/browser_documentation.html new file mode 100644 index 00000000000..6be1267773b --- /dev/null +++ b/3rdparty/simpletest/docs/fr/browser_documentation.html @@ -0,0 +1,500 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : le composant de navigation web scriptable</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur le navigateur scriptable</h1> + This page... + <ul> +<li> + Utiliser le <a href="#scripting">navigateur web dans des scripts</a> + </li> +<li> + <a href="#deboguer">Déboguer</a> les erreurs sur les pages + </li> +<li> + <a href="#unit">Tests complexes avec des navigateurs web multiples</a> + </li> +</ul> +<div class="content"> + + <p> + Le composant de navigation web de SimpleTest peut être utilisé + non seulement à l'extérieur de la classe <span class="new_code">WebTestCase</span>, + mais aussi indépendamment du framework SimpleTest lui-même. + </p> + + <h2> +<a class="target" name="script"></a>Le navigateur scriptable</h2> + <p> + Vous pouvez utiliser le navigateur web dans des scripts PHP + pour confirmer que des services marchent bien comme il faut + ou pour extraire des informations à partir de ceux-ci de façon régulière. + Par exemple, voici un petit script pour extraire + le nombre de bogues ouverts dans PHP 5 à partir + du <a href="http://www.php.net/">site web PHP</a>... +<pre> +<?php + require_once('simpletest/browser.php'); + + $browser = &new SimpleBrowser(); + $browser->get('http://php.net/'); + $browser->clickLink('reporting bugs'); + $browser->clickLink('statistics'); + $browser->clickLink('PHP 5 bugs only'); + $page = $browser->getContent(); + preg_match('/status=Open.*?by=Any.*?(\d+)<\/a>/', $page, $matches); + print $matches[1]; +?> +</pre> + Bien sûr Il y a des méthodes plus simple pour réaliser + cet exemple en PHP. Par exemple, vous pourriez juste + utiliser la commande PHP <span class="new_code">file()</span> sur ce qui est + ici une page fixe. Cependant, en utilisant des scripts + avec le navigateur web vous vous autorisez l'authentification, + la gestion des cookies, le chargement automatique des fenêtres, + les redirections, la transmission de formulaires et la capacité + d'examiner les entêtes. + </p> + <p> + Ces méthodes qui se basent sur le contenu textuel des pages + sont fragiles dans un site en constante évolution + et vous voudrez employer une méthode plus directe + pour accéder aux données de façon permanente, + mais pour des tâches simples cette technique peut s'avérer + une solution très rapide. + </p> + <p> + Toutes les méthode de navigation utilisées dans <a href="web_tester_documentation.html">WebTestCase</a> sont présente dans la classe <span class="new_code">SimpleBrowser</span>, mais les assertions sont remplacées par de simples accesseurs. Voici une liste complète des méthodes de navigation de page à page... + <table><tbody> + <tr> +<td><span class="new_code">addHeader($header)</span></td> +<td>Ajouter une entête à chaque téléchargement</td> +</tr> + <tr> +<td><span class="new_code">useProxy($proxy, $username, $password)</span></td> +<td>Utilise ce proxy à partir de maintenant</td> +</tr> + <tr> +<td><span class="new_code">head($url, $parameters)</span></td> +<td>Effectue une requête HEAD</td> +</tr> + <tr> +<td><span class="new_code">get($url, $parameters)</span></td> +<td>Télécharge une page avec un GET</td> +</tr> + <tr> +<td><span class="new_code">post($url, $parameters)</span></td> +<td>Télécharge une page avec un POST</td> +</tr> + <tr> +<td><span class="new_code">click($label)</span></td> +<td>Suit un lien visible ou un bouton texte par son étiquette</td> +</tr> + <tr> +<td><span class="new_code">clickLink($label)</span></td> +<td>Suit un lien par son étiquette</td> +</tr> + <tr> +<td><span class="new_code">isLink($label)</span></td> +<td>Vérifie l'existance d'un lien par son étiquette</td> +</tr> + <tr> +<td><span class="new_code">clickLinkById($id)</span></td> +<td>Suit un lien par son attribut d'identification</td> +</tr> + <tr> +<td><span class="new_code">isLinkById($id)</span></td> +<td>Vérifie l'existance d'un lien par son attribut d'identification</td> +</tr> + <tr> +<td><span class="new_code">getUrl()</span></td> +<td>La page ou la fenêtre URL en cours</td> +</tr> + <tr> +<td><span class="new_code">getTitle()</span></td> +<td>Le titre de la page</td> +</tr> + <tr> +<td><span class="new_code">getContent()</span></td> +<td>Le page ou la fenêtre brute</td> +</tr> + <tr> +<td><span class="new_code">getContentAsText()</span></td> +<td>Sans code HTML à l'exception du text "alt"</td> +</tr> + <tr> +<td><span class="new_code">retry()</span></td> +<td>Répète la dernière requête</td> +</tr> + <tr> +<td><span class="new_code">back()</span></td> +<td>Utilise le bouton "précédent" du navigateur</td> +</tr> + <tr> +<td><span class="new_code">forward()</span></td> +<td>Utilise le bouton "suivant" du navigateur</td> +</tr> + <tr> +<td><span class="new_code">authenticate($username, $password)</span></td> +<td>Retente la page ou la fenêtre après une réponse 401</td> +</tr> + <tr> +<td><span class="new_code">restart($date)</span></td> +<td>Relance le navigateur pour une nouvelle session</td> +</tr> + <tr> +<td><span class="new_code">ageCookies($interval)</span></td> +<td>Change la date des cookies</td> +</tr> + <tr> +<td><span class="new_code">setCookie($name, $value)</span></td> +<td>Lance un nouveau cookie</td> +</tr> + <tr> +<td><span class="new_code">getCookieValue($host, $path, $name)</span></td> +<td>Lit le cookie le plus spécifique</td> +</tr> + <tr> +<td><span class="new_code">getCurrentCookieValue($name)</span></td> +<td>Lit le contenue du cookie en cours</td> +</tr> + </tbody></table> + Les méthode <span class="new_code">SimpleBrowser::useProxy()</span> et + <span class="new_code">SimpleBrowser::addHeader()</span> sont spéciales. + Une fois appelées, elles continuent à s'appliquer sur les téléchargements suivants. + </p> + <p> + Naviguer dans les formulaires est similaire à la <a href="form_testing_documentation.html">navigation des formulaires via WebTestCase</a>... + <table><tbody> + <tr> +<td><span class="new_code">setField($label, $value)</span></td> +<td>Modifie tous les champs avec cette étiquette ou ce nom</td> +</tr> + <tr> +<td><span class="new_code">setFieldByName($name, $value)</span></td> +<td>Modifie tous les champs avec ce nom</td> +</tr> + <tr> +<td><span class="new_code">setFieldById($id, $value)</span></td> +<td>Modifie tous les champs avec cet identifiant</td> +</tr> + <tr> +<td><span class="new_code">getField($label)</span></td> +<td>Accesseur de la valeur d'un élément de formulaire avec cette étiquette ou ce nom</td> +</tr> + <tr> +<td><span class="new_code">getFieldByName($name)</span></td> +<td>Accesseur de la valeur d'un élément de formulaire avec ce nom</td> +</tr> + <tr> +<td><span class="new_code">getFieldById($id)</span></td> +<td>Accesseur de la valeur de l'élément de formulaire avec cet identifiant</td> +</tr> + <tr> +<td><span class="new_code">clickSubmit($label)</span></td> +<td>Transmet le formulaire avec l'étiquette de son bouton</td> +</tr> + <tr> +<td><span class="new_code">clickSubmitByName($name)</span></td> +<td>Transmet le formulaire avec l'attribut de son bouton</td> +</tr> + <tr> +<td><span class="new_code">clickSubmitById($id)</span></td> +<td>Transmet le formulaire avec l'identifiant de son bouton</td> +</tr> + <tr> +<td><span class="new_code">clickImage($label, $x, $y)</span></td> +<td>Clique sur une balise input de type image par son titre (title="*") our son texte alternatif (alt="*")</td> +</tr> + <tr> +<td><span class="new_code">clickImageByName($name, $x, $y)</span></td> +<td>Clique sur une balise input de type image par son attribut (name="*")</td> +</tr> + <tr> +<td><span class="new_code">clickImageById($id, $x, $y)</span></td> +<td>Clique sur une balise input de type image par son identifiant (id="*")</td> +</tr> + <tr> +<td><span class="new_code">submitFormById($id)</span></td> +<td>Transmet le formulaire par son identifiant propre</td> +</tr> + </tbody></table> + Au jourd d'aujourd'hui il n'existe pas beaucoup de méthodes pour lister + les formulaires et les champs disponibles. + <table><tbody> + <tr> +<td><span class="new_code">isClickable($label)</span></td> +<td>Vérifie si un lien existe avec cette étiquette ou ce nom</td> +</tr> + <tr> +<td><span class="new_code">isSubmit($label)</span></td> +<td>Vérifie si un bouton existe avec cette étiquette ou ce nom</td> +</tr> + <tr> +<td><span class="new_code">isImage($label)</span></td> +<td>Vérifie si un bouton image existe avec cette étiquette ou ce nom</td> +</tr> + <tr> +<td><span class="new_code">getLink($label)</span></td> +<td>Trouve une URL à partir de son label</td> +</tr> + <tr> +<td><span class="new_code">getLinkById($label)</span></td> +<td>Trouve une URL à partir de son identifiant</td> +</tr> + <tr> +<td><span class="new_code">getUrls()</span></td> +<td>Liste l'ensemble des liens de la page courante</td> +</tr> + </tbody></table> + Ce sera probablement + ajouté dans des versions successives de SimpleTest. + </p> + <p> + A l'intérieur d'une page, les fenêtres individuelles peuvent être + sélectionnées. Si aucune sélection n'est réalisée alors + toutes les fenêtres sont fusionnées ensemble dans + une unique et grande page. + Le contenu de la page en cours sera une concaténation des + toutes les fenêtres dans l'ordre spécifié par les balises "frameset". + <table><tbody> + <tr> +<td><span class="new_code">getFrames()</span></td> +<td>Un déchargement de la structure de la fenêtre courante</td> +</tr> + <tr> +<td><span class="new_code">getFrameFocus()</span></td> +<td>L'index ou l'étiquette de la fenêtre en courante</td> +</tr> + <tr> +<td><span class="new_code">setFrameFocusByIndex($choice)</span></td> +<td>Sélectionne la fenêtre numérotée à partir de 1</td> +</tr> + <tr> +<td><span class="new_code">setFrameFocus($name)</span></td> +<td>Sélectionne une fenêtre par son étiquette</td> +</tr> + <tr> +<td><span class="new_code">clearFrameFocus()</span></td> +<td>Traite toutes les fenêtres comme une seule page</td> +</tr> + </tbody></table> + Lorsqu'on est focalisé sur une fenêtre unique, + le contenu viendra de celle-ci uniquement. + Cela comprend les liens à cliquer et les formulaires à transmettre. + </p> + + <h2> +<a class="target" name="deboguer"></a>Où sont les erreurs ?</h2> + <p> + Toute cette masse de fonctionnalités est géniale + lorsqu'on arrive à bien télécharger les pages, + mais ce n'est pas toujours évident. + Pour aider à découvrir les erreurs, le navigateur a aussi + des méthodes pour aider au débogage. + <table><tbody> + <tr> +<td><span class="new_code">setConnectionTimeout($timeout)</span></td> +<td>Ferme la socket avec un délai trop long</td> +</tr> + <tr> +<td><span class="new_code">getUrl()</span></td> +<td>L'URL de la page chargée le plus récemment</td> +</tr> + <tr> +<td><span class="new_code">getRequest()</span></td> +<td>L'entête de la requête brute de la page ou de la fenêtre</td> +</tr> + <tr> +<td><span class="new_code">getHeaders()</span></td> +<td>L'entête de réponse de la page ou de la fenêtre</td> +</tr> + <tr> +<td><span class="new_code">getTransportError()</span></td> +<td>N'importe quel erreur au niveau de la socket dans le dernier téléchargement</td> +</tr> + <tr> +<td><span class="new_code">getResponseCode()</span></td> +<td>La réponse HTTP de la page ou de la fenêtre</td> +</tr> + <tr> +<td><span class="new_code">getMimeType()</span></td> +<td>Le type Mime de la page our de la fenêtre</td> +</tr> + <tr> +<td><span class="new_code">getAuthentication()</span></td> +<td>Le type d'authentification dans l'entête d'une provocation 401</td> +</tr> + <tr> +<td><span class="new_code">getRealm()</span></td> +<td>Le realm d'authentification dans l'entête d'une provocation 401</td> +</tr> + <tr> +<td><span class="new_code">getBaseUrl()</span></td> +<td>Uniquement la base de l'URL de la page chargée le plus récemment</td> +</tr> + <tr> +<td><span class="new_code">setMaximumRedirects($max)</span></td> +<td>Nombre de redirections avant que la page ne soit chargée automatiquement</td> +</tr> + <tr> +<td><span class="new_code">setMaximumNestedFrames($max)</span></td> +<td>Protection contre des framesets récursifs</td> +</tr> + <tr> +<td><span class="new_code">ignoreFrames()</span></td> +<td>Neutralise le support des fenêtres</td> +</tr> + <tr> +<td><span class="new_code">useFrames()</span></td> +<td>Autorise le support des fenêtres</td> +</tr> + </tbody></table> + Les méthodes <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> + et <span class="new_code">SimpleBrowser::useFrames()</span> continuent à s'appliquer + sur toutes les requêtes suivantes. + Les autres méthodes tiennent compte des fenêtres. + Cela veut dire que si une fenêtre individuelle ne se charge pas, + il suffit de se diriger vers elle avec + <span class="new_code">SimpleBrowser::setFrameFocus()</span> : ensuite on utilisera + <span class="new_code">SimpleBrowser::getRequest()</span>, etc. pour voir ce qui se passe. + </p> + + <h2> +<a class="target" name="unit"></a>Tests unitaires complexes avec des navigateurs multiples</h2> + <p> + Tout ce qui peut être fait dans + <a href="web_tester_documentation.html">WebTestCase</a> peut maintenant + être fait dans un <a href="unit_tester_documentation.html">UnitTestCase</a>. + Ce qui revient à dire que nous pouvons librement mélanger + des tests sur des objets de domaine avec l'interface web... +<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->clickSubmit('Register'); + <strong> + $authenticator = new Authenticator(); + $member = $authenticator->findByEmail('me@here'); + $this->assertEqual($member->getPassword(), 'Secret');</strong> + } +} +</pre> + Bien que ça puisse être utile par convenance temporaire, + je ne suis pas fan de ce genre de test. Ce test s'applique + à plusieurs couches de l'application, ça implique qu'il est + plus que probable qu'il faudra le remanier lorsque le code changera. + </p> + <p> + Un cas plus utile d'utilisation directe du navigateur est + le moment où le <span class="new_code">WebTestCase</span> ne peut plus suivre. + Un exemple ? Quand deux navigateurs doivent être utilisés en même temps. + </p> + <p> + Par exemple, supposons que nous voulions interdire + des usages simultanés d'un site avec le même login d'identification. + Ce scénario de test le vérifie... +<pre> +class TestOfSecurity extends UnitTestCase { + function testNoMultipleLoginsFromSameUser() { + $first = &new SimpleBrowser(); + $first->get('http://my-site.com/login.php'); + $first->setField('name', 'Me'); + $first->setField('password', 'Secret'); + $first->clickSubmit('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->clickSubmit('Enter'); + $this->assertEqual($second->getTitle(), 'Access Denied'); + } +} +</pre> + Vous pouvez aussi utiliser la classe <span class="new_code">SimpleBrowser</span> + quand vous souhaitez écrire des scénarios de test en utilisant + un autre outil que SimpleTest, comme PHPUnit par exemple. + </p> + + </div> + References and related information... + <ul> +<li> + La page du projet SimpleTest sur + <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page de téléchargement de SimpleTest sur + <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + <a href="http://simpletest.org/api/">L'API de développeur pour SimpleTest</a> + donne tous les détails sur les classes et les assertions disponibles. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/docs.css b/3rdparty/simpletest/docs/fr/docs.css new file mode 100755 index 00000000000..49170486ab3 --- /dev/null +++ b/3rdparty/simpletest/docs/fr/docs.css @@ -0,0 +1,84 @@ +body { + padding-left: 3%; + padding-right: 3%; +} +pre { + font-family: "courier new", 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/3rdparty/simpletest/docs/fr/expectation_documentation.html b/3rdparty/simpletest/docs/fr/expectation_documentation.html new file mode 100644 index 00000000000..ee579110a6d --- /dev/null +++ b/3rdparty/simpletest/docs/fr/expectation_documentation.html @@ -0,0 +1,451 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : étendre le testeur unitaire avec des classes d'attentes supplémentaires</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur les attentes</h1> + This page... + <ul> +<li> + Utiliser les attentes <a href="#fantaisie">pour des tests + plus précis avec des objets fantaisie</a> + </li> +<li> + <a href="#comportement">Changer le comportement d'un objet fantaisie</a> + avec des attentes + </li> +<li> + <a href="#etendre">Créer des attentes</a> + </li> +<li> + Par dessous SimpleTest <a href="#unitaire">utilise des classes d'attente</a> + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="fantaisie"></a>Plus de contrôle sur les objets fantaisie</h2> + <p> + Le comportement par défaut des + <a href="mock_objects_documentation.html">objets fantaisie</a> dans + <a href="http://sourceforge.net/projects/simpletest/">SimpleTest</a> + est soit une correspondance identique sur l'argument, + soit l'acceptation de n'importe quel argument. + Pour la plupart des tests, c'est suffisant. + Cependant il est parfois nécessaire de ramollir un scénario de test. + </p> + <p> + Un des endroits où un test peut être trop serré + est la reconnaissance textuelle. Prenons l'exemple + d'un composant qui produirait un message d'erreur + utile lorsque quelque chose plante. Il serait utile de tester + que l'erreur correcte est renvoyée, + mais le texte proprement dit risque d'être plutôt long. + Si vous testez le texte dans son ensemble alors + à chaque modification de ce même message + -- même un point ou une virgule -- vous aurez + à revenir sur la suite de test pour la modifier. + </p> + <p> + Voici un cas concret, nous avons un service d'actualités + qui a échoué dans sa tentative de connexion à sa source distante. +<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> + Là il envoie son contenu vers un classe <span class="new_code">Writer</span>. + Nous pourrions tester ce comportement avec un <span class="new_code">MockWriter</span>... +<pre> +class TestOfNewsService extends UnitTestCase { + ... + function testConnectionFailure() {<strong> + $writer = new MockWriter($this); + $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); + + $writer->tally();</strong> + } +} +</pre> + C'est un bon exemple d'un test fragile. + Si nous décidons d'ajouter des instructions complémentaires, + par exemple proposer une source d'actualités alternative, + nous casserons nos tests par la même occasion sans pourtant + avoir modifié une seule fonctionnalité. + </p> + <p> + Pour contourner ce problème, nous voudrions utiliser + un test avec une expression rationnelle plutôt + qu'une correspondance exacte. Nous pouvons y parvenir avec... +<pre> +class TestOfNewsService extends UnitTestCase { + ... + function testConnectionFailure() { + $writer = new MockWriter($this);<strong> + $writer->expectOnce( + 'write', + array(new PatternExpectation('/cannot connect/i')));</strong> + + $service = new NewsService('BBC News'); + $service->publish($writer); + + $writer->tally(); + } +} +</pre> + Plutôt que de transmettre le paramètre attendu au <span class="new_code">MockWriter</span>, + nous envoyons une classe d'attente appelée <span class="new_code">PatternExpectation</span>. + L'objet fantaisie est suffisamment élégant pour reconnaître + qu'il s'agit d'un truc spécial et pour le traiter différemment. + Plutôt que de comparer l'argument entrant à cet objet, + il utilise l'objet attente lui-même pour exécuter le test. + </p> + <p> + <span class="new_code">PatternExpectation</span> utilise + l'expression rationnelle pour la comparaison avec son constructeur. + A chaque fois qu'une comparaison est fait à travers + <span class="new_code">MockWriter</span> par rapport à cette classe attente, + elle fera un <span class="new_code">preg_match()</span> avec ce motif. + Dans notre scénario de test ci-dessus, aussi longtemps + que la chaîne "cannot connect" apparaît dans le texte, + la fantaisie transmettra un succès au testeur unitaire. + Peu importe le reste du texte. + </p> + <p> + Les classes attente possibles sont... + <table><tbody> + <tr> +<td><span class="new_code">AnythingExpectation</span></td> +<td>Sera toujours validé</td> +</tr> + <tr> +<td><span class="new_code">EqualExpectation</span></td> +<td>Une égalité, plutôt que la plus forte comparaison à l'identique</td> +</tr> + <tr> +<td><span class="new_code">NotEqualExpectation</span></td> +<td>Une comparaison sur la non-égalité</td> +</tr> + <tr> +<td><span class="new_code">IndenticalExpectation</span></td> +<td>La vérification par défaut de l'objet fantaisie qui doit correspondre exactement</td> +</tr> + <tr> +<td><span class="new_code">NotIndenticalExpectation</span></td> +<td>Inverse la logique de l'objet fantaisie</td> +</tr> + <tr> +<td><span class="new_code">PatternExpectation</span></td> +<td>Utilise une expression rationnelle Perl pour comparer une chaîne</td> +</tr> + <tr> +<td><span class="new_code">NoPatternExpectation</span></td> +<td>Passe seulement si l'expression rationnelle Perl échoue</td> +</tr> + <tr> +<td><span class="new_code">IsAExpectation</span></td> +<td>Vérifie le type ou le nom de la classe uniquement</td> +</tr> + <tr> +<td><span class="new_code">NotAExpectation</span></td> +<td>L'opposé de <span class="new_code">IsAExpectation</span> +</td> +</tr> + <tr> +<td><span class="new_code">MethodExistsExpectation</span></td> +<td>Vérifie si la méthode est disponible sur un objet</td> +</tr> + <tr> +<td><span class="new_code">TrueExpectation</span></td> +<td>Accepte n'importe quelle variable PHP qui vaut vrai</td> +</tr> + <tr> +<td><span class="new_code">FalseExpectation</span></td> +<td>Accepte n'importe quelle variable PHP qui vaut faux</td> +</tr> + </tbody></table> + La plupart utilisent la valeur attendue dans le constructeur. + Les exceptions sont les vérifications sur motif, + qui utilisent une expression rationnelle, ainsi que + <span class="new_code">IsAExpectation</span> et <span class="new_code">NotAExpectation</span>, + qui prennent un type ou un nom de classe comme chaîne. + </p> + + <h2> +<a class="target" name="comportement"></a>Utiliser les attentes pour contrôler les bouchons serveur</h2> + <p> + Les classes attente peuvent servir à autre chose + que l'envoi d'assertions depuis les objets fantaisie, + afin de choisir le comportement d'un + <a href="mock_objects_documentation.html">objet fantaisie</a> + ou celui d'un <a href="server_stubs_documentation.html">bouchon serveur</a>. + A chaque fois qu'une liste d'arguments est donnée, + une liste d'objets d'attente peut être insérée à la place. + </p> + <p> + Mettons que nous voulons qu'un bouchon serveur + d'autorisation simule une connexion réussie seulement + si il reçoit un objet de session valide. + Nous pouvons y arriver avec ce qui suit... +<pre> +Stub::generate('Authorisation'); +<strong> +$authorisation = new StubAuthorisation(); +$authorisation->returns( + 'isAllowed', + true, + array(new IsAExpectation('Session', 'Must be a session'))); +$authorisation->returns('isAllowed', false);</strong> +</pre> + Le comportement par défaut du bouchon serveur + est défini pour renvoyer <span class="new_code">false</span> + quand <span class="new_code">isAllowed</span> est appelé. + Lorsque nous appelons cette méthode avec un unique paramètre + qui est un objet <span class="new_code">Session</span>, il renverra <span class="new_code">true</span>. + Nous avons aussi ajouté un deuxième paramètre comme message. + Il sera affiché dans le message d'erreur de l'objet fantaisie + si l'attente est la cause de l'échec. + </p> + <p> + Ce niveau de sophistication est rarement utile : + il n'est inclut que pour être complet. + </p> + + <h2> +<a class="target" name="etendre"></a>Créer vos propres attentes</h2> + <p> + Les classes d'attentes ont une structure très simple. + Tellement simple qu'il devient très simple de créer + vos propres version de logique pour des tests utilisés couramment. + </p> + <p> + Par exemple voici la création d'une classe pour tester + la validité d'adresses IP. Pour fonctionner correctement + avec les bouchons serveurs et les objets fantaisie, + cette nouvelle classe d'attente devrait étendre + <span class="new_code">SimpleExpectation</span> ou une autre de ses sous-classes... +<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> + Il n'y a véritablement que deux méthodes à mettre en place. + La méthode <span class="new_code">test()</span> devrait renvoyer un <span class="new_code">true</span> + si l'attente doit passer, et une erreur <span class="new_code">false</span> + dans le cas contraire. La méthode <span class="new_code">testMessage()</span> + ne devrait renvoyer que du texte utile à la compréhension du test en lui-même. + </p> + <p> + Cette classe peut désormais être employée à la place + des classes d'attente précédentes. + </p> + <p> + Voici un exemple plus typique, vérifier un hash... +<pre> +<strong>class JustField extends EqualExpectation { + private $key; + + function __construct($key, $expected) { + parent::__construct($expected); + $this->key = $key; + } + + function test($compare) { + if (! isset($compare[$this->key])) { + return false; + } + return parent::test($compare[$this->key]); + } + + function testMessage($compare) { + if (! isset($compare[$this->key])) { + return 'Key [' . $this->key . '] does not exist'; + } + return 'Key [' . $this->key . '] -> ' . + parent::testMessage($compare[$this->key]); + } +}</strong> +</pre> + L'habitude a été prise pour séparer les clauses du message avec + "&nbsp;->&nbsp;". + Cela permet aux outils dérivés de reformater la sortie. + </p> + <p> + Supposons qu'un authentificateur s'attend à recevoir + une ligne de base de données correspondant à l'utilisateur, + et que nous avons juste besoin de valider le nom d'utilisateur. + Nous pouvons le faire très simplement avec... +<pre> +$mock->expectOnce('authenticate', + array(new JustKey('username', 'marcus'))); +</pre> + </p> + + <h2> +<a class="target" name="unitaire"></a>Sous le capot du testeur unitaire</h2> + <p> + Le <a href="http://sourceforge.net/projects/simpletest/">framework + de test unitaire SimpleTest</a> utilise aussi dans son coeur + des classes d'attente pour + la <a href="unit_test_documentation.html">classe UnitTestCase</a>. + Nous pouvons aussi tirer parti de ces mécanismes pour réutiliser + nos propres classes attente à l'intérieur même des suites de test. + </p> + <p> + La méthode la plus directe est d'utiliser la méthode + <span class="new_code">SimpleTest::assert()</span> pour effectuer le test... +<pre> +<strong>class TestOfNetworking extends UnitTestCase { + ... + function testGetValidIp() { + $server = &new Server(); + $this->assert( + new ValidIp(), + $server->getIp(), + 'Server IP address->%s'); + } +}</strong> +</pre> + <span class="new_code">assert()</span> testera toute attente directement. + </p> + <p> + C'est plutôt sale par rapport à notre syntaxe habituelle + du type <span class="new_code">assert...()</span>. + </p> + <p> + Pour un cas aussi simple, nous créons d'ordinaire une méthode + d'assertion distincte en utilisant la classe d'attente. + Supposons un instant que notre attente soit un peu plus + compliquée et que par conséquent nous souhaitions la réutiliser, + nous obtenons... +<pre> +class TestOfNetworking extends UnitTestCase { + ...<strong> + function assertValidIp($ip, $message = '%s') { + $this->assertExpectation(new ValidIp(), $ip, $message); + }</strong> + + function testGetValidIp() { + $server = &new Server();<strong> + $this->assertValidIp( + $server->getIp(), + 'Server IP address->%s');</strong> + } +} +</pre> + It is rare to need the expectations for more than pattern + matching, but these facilities do allow testers to build + some sort of domain language for testing their application. + Also, complex expectation classes could make the tests + harder to read and debug. + In effect extending the test framework to create their own tool set. + + + Il est assez rare que le besoin d'une attente dépasse + le stade de la reconnaissance d'un motif, mais ils permettent + aux testeurs de construire leur propre langage dédié ou DSL + (Domain Specific Language) pour tester leurs applications. + Attention, les classes d'attente complexes peuvent rendre + les tests difficiles à lire et à déboguer. + Ces mécanismes sont véritablement là pour les auteurs + de système qui étendront le framework de test + pour leurs propres outils de test. + </p> + + </div> + References and related information... + <ul> +<li> + La page du projet SimpleTest sur + <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page de téléchargement de SimpleTest sur + <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + Les attentes imitent les contraintes dans + <a href="http://www.jmock.org/">JMock</a>. + </li> +<li> + <a href="http://simpletest.org/api/">L'API complète pour SimpleTest</a> + réalisé avec PHPDoc. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/form_testing_documentation.html b/3rdparty/simpletest/docs/fr/form_testing_documentation.html new file mode 100644 index 00000000000..e3cb6a10a19 --- /dev/null +++ b/3rdparty/simpletest/docs/fr/form_testing_documentation.html @@ -0,0 +1,363 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : tester des formulaires HTML</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur les tests de formulaire</h1> + This page... + <ul> +<li> + Modifier les valeurs d'un formulaire et + <a href="#submit">réussir à transmettre un simple formulaire</a> + </li> +<li> + Gérer des <a href="#multiple">objets à valeurs multiples</a> + en initialisant des listes. + </li> +<li> + Le cas des formulaires utilisant Javascript pour + modifier <a href="#hidden-field">un champ caché</a> + </li> +<li> + <a href="#brut">Envoi brut</a> quand il n'existe pas de bouton à cliquer. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="submit"></a>Valider un formulaire simple</h2> + <p> + Lorsqu'une page est téléchargée par <span class="new_code">WebTestCase</span> + en utilisant <span class="new_code">get()</span> ou <span class="new_code">post()</span> + le contenu de la page est automatiquement analysé. + De cette analyse découle le fait que toutes les commandes + à l'intérieur de la balise <form> sont disponibles + depuis l'intérieur du scénario de test. + Prenons par exemple cet extrait de code HTML... +<pre> +<form> + <input type="text" name="a" value="A default" /> + <input type="submit" value="Go" /> +</form> +</pre> + Il ressemble à... + </p> + <p> + <form class="demo"> + <input type="text" name="a" value="A default"> + <input type="submit" value="Go"> + </form> + </p> + <p> + Nous pouvons naviguer vers ce code, via le site + <a href="http://www.lastcraft.com/form_testing_documentation.php">LastCraft</a>, + avec le test suivant... +<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> + Directement après le chargement de la page toutes les commandes HTML + sont initiées avec leur valeur par défaut, comme elles apparaîtraient + dans un navigateur web. L'assertion teste qu'un objet HTML + avec le nom "a" existe dans la page + et qu'il contient la valeur "A default". + </p> + <p> + Nous pourrions retourner le formulaire tout de suite... +<pre> +class SimpleFormTests extends WebTestCase { + function testDefaultValue() { + $this->get('http://www.lastcraft.com/form_testing_documentation.php'); + $this->assertField('a', <strong>new PatternExpectation('/default/')</strong>); + } +} +</pre> + Mais d'abord nous allons changer la valeur du champ texte. + Ce n'est qu'après que nous le transmettrons... +<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->clickSubmit('Go');</strong> + } +} +</pre> + Parce que nous n'avons spécifié ni attribut "method" + sur la balise form, ni attribut "action", + le scénario de test suivra le comportement classique d'un navigateur : + transmission des données avec une requête <em>GET</em> + vers la même page. En règle générale SimpleTest essaie d'émuler + le comportement typique d'un navigateur autant que possible, + plutôt que d'essayer d'attraper des attributs manquants sur les balises. + La raison est simple : la cible d'un framework de test est + la logique d'une application PHP, pas les erreurs + -- de syntaxe ou autres -- du code HTML. + Pour les erreurs HTML, d'autres outils tel + <a href="http://www.w3.org/People/Raggett/tidy/">HTMLTidy</a> + devraient être employés, ou même n'importe lequel des validateurs HTML et CSS + déjà sur le marché. + </p> + <p> + Si un champ manque dans n'importe quel formulaire ou si + une option est indisponible alors <span class="new_code">WebTestCase::setField()</span> + renverra <span class="new_code">false</span>. Par exemple, supposons que + nous souhaitons vérifier qu'une option "Superuser" + n'est pas présente dans ce formulaire... +<pre> +<strong>Select type of user to add:</strong> +<select name="type"> + <option>Subscriber</option> + <option>Author</option> + <option>Administrator</option> +</select> +</pre> + Qui ressemble à... + </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> + Le test suivant le confirmera... +<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> + La sélection ne sera pas changée si la nouvelle valeur n'est pas une des options. + </p> + <p> + Voici la liste complète des objets supportés à aujourd'hui... + <ul> + <li>Champs texte, y compris les champs masqués (hidden) ou cryptés (password).</li> + <li>Boutons submit, en incluant aussi la balise button, mais pas encore les boutons reset</li> + <li>Aires texte (textarea) avec leur gestion des retours à la ligne (wrap).</li> + <li>Cases à cocher, y compris les cases à cocher multiples dans un même formulaire.</li> + <li>Listes à menu déroulant, y compris celles à sélections multiples.</li> + <li>Boutons radio.</li> + <li>Images.</li> + </ul> + </p> + <p> + Le navigateur proposé par SimpleTest émule les actions + qui peuvent être réalisées par un utilisateur sur + une page HTML standard. Javascript n'est pas supporté et + il y a peu de chance pour qu'il le soit prochainement. + </p> + <p> + Une attention particulière doit être porté aux techniques Javascript + qui changent la valeur d'un champ caché : elles ne peuvent pas être + réalisées avec les commandes classiques de SimpleTest. + Une méthode alternative est proposée plus loin. + </p> + + <h2> +<a class="target" name="multiple"></a>Champs à valeurs multiples</h2> + <p> + SimpleTest peut gérer deux types de commandes à valeur multiple : + les menus déroulants à sélection multiple et les cases à cocher + avec le même nom à l'intérieur même d'un formulaire. + La nature de ceux-ci implique que leur initialisation + et leur test sont légèrement différents. + Voici un exemple avec des cases à cocher... +<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> + Qui se traduit par... + </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> + Si nous souhaitons désactiver tous les privilèges sauf + ceux de téléchargement (Retrieve) et transmettre cette information, + nous pouvons y arriver par... +<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->clickSubmit('Enable Privileges'); + }</strong> +} +</pre> + Plutôt que d'initier le champ à une valeur unique, + nous lui donnons une liste de valeurs. + Nous faisons la même chose pour tester les valeurs attendues. + Nous pouvons écrire d'autres bouts de code de test + pour confirmer cet effet, peut-être en nous connectant + comme utilisateur et en essayant d'effectuer une mise à jour. + </p> + + <h2> +<a class="target" name="hidden-field"></a>Formulaires utilisant Javascript pour changer un champ caché</h2> + <p> + Si vous souhaitez tester un formulaire dépendant de Javascript + pour la modification d'un champ caché, vous ne pouvez pas + simplement utiliser setField(). + Le code suivant <em>ne fonctionnera pas</em> : +<pre> +class SimpleFormTests extends WebTestCase { + function testEmulateMyJavascriptForm() { + <strong>// This does *not* work</strong> + $this->setField('a_hidden_field', '123'); + $this->clickSubmit('OK'); + } +} +</pre> + A la place, vous aurez besoin d'ajouter le paramètre supplémentaire + du formulaire à la méthode clickSubmit() : +<pre> +class SimpleFormTests extends WebTestCase { + function testMyJavascriptForm() { + <strong>$this->clickSubmit('OK', array('a_hidden_field'=>'123'));</strong> + } + +} +</pre> + </p> + <p> + N'oubliez pas que de la sorte, vous êtes effectivement en train + de court-circuitez une partie de votre application (le code Javascript + dans le formulaire) et que peut-être serait-il plus prudent + d'utiliser un outil comme + <a href="http://selenium.openqa.org/">Selenium</a> pour mettre sur pied + un test complet. + </p> + + <h2> +<a class="target" name="brut"></a>Envoi brut</h2> + <p> + Si vous souhaitez tester un gestionnaire de formulaire + mais que vous ne l'avez pas écrit ou que vous n'y avez + pas encore accès, vous pouvez créer un envoi de formulaire à la main. +<pre> +class SimpleFormTests extends WebTestCase { + ...<strong> + function testAttemptedHack() { + $this->post( + 'http://www.my-site.com/add_user.php', + array('type' => 'superuser')); + $this->assertNoUnwantedPattern('/user created/i'); + }</strong> +} +</pre> + En ajoutant des données à la méthode <span class="new_code">WebTestCase::post()</span>, + nous émulons la transmission d'un formulaire. + D'ordinaire, vous ne ferez cela que pour parer au plus pressé, + ou alors si vous espérez un tiers (javascript ?) transmette le formulaire. + Il reste quand même exception : si vous souhaitez vous protégez + d'attaques de type "spoofing". + </p> + + </div> + References and related information... + <ul> +<li> + La page du projet SimpleTest sur + <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page de téléchargement de SimpleTest sur + <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + <a href="http://simpletest.org/api/">L'API du développeur pour SimpleTest</a> + donne tous les détails sur les classes et les assertions disponibles. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/group_test_documentation.html b/3rdparty/simpletest/docs/fr/group_test_documentation.html new file mode 100644 index 00000000000..fb546af4603 --- /dev/null +++ b/3rdparty/simpletest/docs/fr/group_test_documentation.html @@ -0,0 +1,265 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : Grouper des tests</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur le groupement des tests</h1> + This page... + <ul> +<li> + Plusieurs approches pour <a href="#group">grouper des tests</a> ensemble. + </li> +<li> + Combiner des groupes des tests dans des + <a href="#plus-haut">groupes plus grands</a>. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="grouper"></a>Grouper des tests</h2> + <p> + Il existe beaucoup de moyens pour grouper des tests dans des suites de tests. + Le premier d'entre eux est tout simplement ajouter tous les scénarios de test + au fur et à mesure d'un unique fichier... +<pre> +<strong><?php +require_once(dirname(__FILE__) . '/simpletest/autorun.php'); +require_once(dirname(__FILE__) . '/../classes/io.php'); + +class FileTester extends UnitTestCase { + ... +} + +class SocketTester extends UnitTestCase { + ... +} +?></strong> +</pre> + Autant de scénarios que nécessaires peuvent être + mis dans cet unique fichier. Ils doivent contenir + tout le code nécessaire, entre autres la bibliothèque testée, + mais aucune des bibliothèques de SimpleTest. + </p> + <p> + Occasionnellement des sous-classes spéciales sont créés pour + ajouter des méthodes nécessaires à certains tests spécifiques + au sein de l'application. + Ces nouvelles classes de base sont ensuite utilisées + à la place de <span class="new_code">UnitTestCase</span> + ou de <span class="new_code">WebTestCase</span>. + Bien sûr vous ne souhaitez pas les lancer en tant que + scénario de tests : il suffit alors de les identifier + comme "abstraites"... +<pre> +<strong>abstract</strong> class MyFileTestCase extends UnitTestCase { + ... +} + +class FileTester extends MyFileTestCase { ... } + +class SocketTester extends UnitTestCase { ... } +</pre> + La classe <span class="new_code">FileTester</span> ne contient aucun test véritable, + il s'agit d'une classe de base pour d'autres scénarios de test. + </p> + <p> + Nous appelons ce fichier <em>file_test.php</em>. + Pour l'instant les scénarios de tests sont simplement groupés dans le même fichier. + Nous pouvons mettre en place des structures plus importantes + en incluant d'autres fichiers de tests. +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('file_test.php'); +?> +</pre> + Ceci fontionnera, tout en créant une hiérarchie tout à fait plate. + A la place, nous créons un fichier de suite de tests. + Notre suite des tests de premier niveau devient... +<pre> +<?php +require_once('simpletest/autorun.php'); + +class AllFileTests extends TestSuite { + function __construct() { + parent::__construct(); + <strong>$this->addFile('file_test.php');</strong> + } +} +?> +</pre> + Voici ce qui arrive : la class <span class="new_code">TestSuite</span> + effecturera le <span class="new_code">require_once()</span> pour nous. + Ensuite elle vérifie si de nouvelles classes de test + ont été créées par ce nouveau fichier et les inclut + automatiquement dans la suite de tests. + Cette méthode nous donne un maximum de contrôle + tout comme le ferait des ajouts manuels de fichiers de tests + au fur et à mesure où notre suite grandit. + </p> + <p> + Si c'est trop de boulot pour vos petits doigts et qu'en plus + vous avez envie de grouper vos suites de tests par répertoire + ou par un tag dans le nom des fichiers, alors il y a un moyen + encore plus automatique... +<pre> +<?php +require_once('simpletest/autorun.php'); + +class AllFileTests extends TestSuite { + function __construct() { + parent::__construct(); + $this->collect(dirname(__FILE__) . '/unit', + new SimplePatternCollector('/_test.php/')); + } +} +?> +</pre> + Cette fonctionnalités va scanner un répertoire appelé "unit", + y détecter tous les fichiers finissant par "_test.php" + et les charger. + Vous n'avez pas besoin d'utiliser <span class="new_code">SimplePatternCollector</span> pour + filtrer en fonction d'un motif dans le nom de fichier, + mais c'est son usage le plus courant. + </p> + <p> + Ce morceau de code est très courant. + Désormais la seule chose qu'il vous reste à faire, c'est de + déposer un fichier avec des scénarios de tests dans ce répertoire + et il sera lancé directement par le script de la suite de tests. + </p> + <p> + Juste un bémol : vous ne pouvez pas contrôler l'ordre de lancement + des tests. + Si vous souhaitez voir des composants de bas niveau renvoyer leurs erreurs + dès le début de la suite de tests - en particulier pour se facilier le travail + de diagnostic - alors vous devriez plutôt passer par <span class="new_code">addFile()</span> + pour ces cas spécifiques. + Les scénarios de tests ne sont chargés qu'une fois, pas d'inquiétude donc + lors du scan de votre répertoire avec tous les tests. + </p> + <p> + Les tests chargés avec la méthode <span class="new_code">addFile</span> ont certaines propriétés + qui peuvent s'avérer intéressantes. + Elle vous assure que le constructeur est lancé avant la première méthode + de test et que le destructeur est lancé après la dernière méthode de test. + Cela vous permet de placer une initialisation (setUp et tearDown) globale + au sein de ce destructeur et desctructeur, comme dans n'importe + quelle classe. + </p> + + <h2> +<a class="target" name="plus-haut"></a>Groupements de plus haut niveau</h2> + <p> + La technique ci-dessus place tous les scénarios de test + dans un unique et grand groupe. + Sauf que pour des projets plus conséquents, + ce n'est probablement pas assez souple; + vous voudriez peut-être grouper les tests tout à fait différemment. + </p> +<p> + Tout ce que nous avons décrit avec des scripts de tests + s'applique pareillement avec des <span class="new_code">TestSuite</span>s... +<pre> +<?php +require_once('simpletest/autorun.php'); +<strong> +class BigTestSuite extends TestSuite { + function __construct() { + parent::__construct(); + $this->addFile('file_tests.php'); + } +}</strong> +?> +</pre> + Cette opération additionne nos scénarios de tests et une unique suite + sous la première. + Quand un test échoue, nous voyons le fil d'ariane avec l'enchainement. + Nous pouvons même mélanger groupes et tests librement en prenant + quand même soin d'éviter les inclusions en boucle. +<pre> +<?php +require_once('simpletest/autorun.php'); + +class BigTestSuite extends TestSuite { + function __construct() { + parent::__construct(); + $this->addFile('file_tests.php'); + <strong>$this->addFile('some_other_test.php');</strong> + } +} +?> +</pre> + Petite précision, en cas de double inclusion, seule la première instance + sera lancée. + </p> + + </div> + References and related information... + <ul> +<li> + La page du projet SimpleTest sur + <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page de téléchargement de SimpleTest sur + <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/index.html b/3rdparty/simpletest/docs/fr/index.html new file mode 100644 index 00000000000..f7e022c36ec --- /dev/null +++ b/3rdparty/simpletest/docs/fr/index.html @@ -0,0 +1,576 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title> + Prise en main rapide de SimpleTest pour PHP - + Tests unitaire et objets fantaisie pour PHP + </title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Prise en main rapide de SimpleTest</h1> + This page... + <ul> +<li> + <a href="#unit">Utiliser le testeur rapidement</a> + avec un exemple. + </li> +<li> + <a href="#group">Groupes de tests</a> + pour tester en un seul clic. + </li> +<li> + <a href="#mock">Utiliser les objets fantaisie</a> + pour faciliter les tests et gagner en contrôle. + </li> +<li> + <a href="#web">Tester des pages web</a> + au niveau de l'HTML. + </li> +</ul> +<div class="content"> + + <p> + Le présent article présuppose que vous soyez familier avec + le concept de tests unitaires ainsi que celui de développement + web avec le langage PHP. Il s'agit d'un guide pour le nouvel + et impatient utilisateur de + <a href="https://sourceforge.net/project/showfiles.php?group_id=76550">SimpleTest</a>. + Pour une documentation plus complète, particulièrement si + vous découvrez les tests unitaires, consultez la + <a href="http://www.lastcraft.com/unit_test_documentation.php">documentation + en cours</a>, et pour des exemples de scénarios de test, + consultez le + <a href="http://www.lastcraft.com/first_test_tutorial.php">tutorial + sur les tests unitaires</a>. + </p> + + <h2> +<a class="target" name="unit"></a>Utiliser le testeur rapidement</h2> + <p> + Parmi les outils de test pour logiciel, le testeur unitaire + est le plus proche du développeur. Dans un contexte de + développement agile, le code de test se place juste à côté + du code source étant donné que tous les deux sont écrits + simultanément. Dans ce contexte, SimpleTest aspire à être + une solution complète de test pour un développeur PHP et + s'appelle "Simple" parce qu'elle devrait être simple à + utiliser et à étendre. Ce nom n'était pas vraiment un bon + choix. Non seulement cette solution inclut toutes les + fonctions classiques qu'on est en droit d'attendre de la + part des portages de <a href="http://www.junit.org/">JUnit</a> et des <a href="http://sourceforge.net/projects/phpunit/">PHPUnit</a>, + mais elle inclut aussi les <a href="http://www.mockobjects.com/">objets fantaisie ou + "mock objects"</a>. + </p> + <p> + Ce qui rend cet outil immédiatement utile pour un développeur PHP, + c'est son navigateur web interne. + Il permet des tests qui parcourent des sites web, remplissent + des formulaires et testent le contenu des pages. + Etre capable d'écrire ces tests en PHP veut dire qu'il devient + facile d'écrire des tests de recette (ou d'intégration). + Un exemple serait de confirmer qu'un utilisateur a bien été ajouté + dans une base de données après s'être enregistré sur une site web. + </p> + <p> + La démonstration la plus rapide : l'exemple + </p> + <p> + Supposons que nous sommes en train de tester une simple + classe de log dans un fichier : elle s'appelle + <span class="new_code">Log</span> dans <em>classes/Log.php</em>. Commençons + par créer un script de test, appelé + <em>tests/log_test.php</em>. Son contenu est le suivant... +<pre> +<?php +<strong>require_once('simpletest/autorun.php');</strong> +require_once('../classes/log.php'); + +class TestOfLogging extends <strong>UnitTestCase</strong> { +} +?> +</pre> + Ici le répertoire <em>simpletest</em> est soit dans le + dossier courant, soit dans les dossiers pour fichiers + inclus. Vous auriez à éditer ces arborescences suivant + l'endroit où vous avez installé SimpleTest. + Le fichier "autorun.php" fait plus que juste inclure + les éléments de SimpleTest : il lance aussi les tests pour nous. + </p> + <p> + <span class="new_code">TestOfLogging</span> est notre premier scénario de test + et il est pour l'instant vide. + Chaque scénario de test est une classe qui étend une des classes + de base de SimpleTest. Nous pouvons avoir autant de classes de ce type + que nous voulons. + </p> + <p> + Avec ces trois lignes d'échafaudage + l'inclusion de notre classe <span class="new_code">Log</span>, nous avons une suite + de tests. Mais pas encore de test ! + </p> + <p> + Pour notre premier test, supposons que la classe <span class="new_code">Log</span> + prenne le nom du fichier à écrire au sein du constructeur, + et que nous avons un répertoire temporaire dans lequel placer + ce fichier. +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('../classes/log.php'); + +class TestOfLogging extends UnitTestCase { + function <strong>testLogCreatesNewFileOnFirstMessage()</strong> { + @unlink('/temp/test.log'); + $log = new Log('/temp/test.log'); + <strong>$this->assertFalse(file_exists('/temp/test.log'));</strong> + $log->message('Should write this to a file'); + <strong>$this->assertTrue(file_exists('/temp/test.log'));</strong> + } +} +?> +</pre> + Au lancement du scénario de test, toutes les méthodes qui + commencent avec la chaîne <span class="new_code">test</span> sont + identifiées puis exécutées. + Si la méthode commence par <span class="new_code">test</span>, c'est un test. + Remarquez bien le nom très long de notre exemple : + <span class="new_code">testLogCreatesNewFileOnFirstMessage()</span>. + C'est bel et bien délibéré : ce style est considéré désirable + et il rend la sortie du test plus lisible. + </p> + <p> + D'ordinaire nous avons bien plusieurs méthodes de tests. + Mais ce sera pour plus tard. + </p> + <p> + Les assertions dans les + méthodes de test envoient des messages vers le framework de + test qui affiche immédiatement le résultat. Cette réponse + immédiate est importante, non seulement lors d'un crash + causé par le code, mais aussi de manière à rapprocher + l'affichage de l'erreur au plus près du scénario de test + concerné via un appel à <span class="new_code">print</span>code>. + </p> + <p> + Pour voir ces résultats lançons effectivement les tests. + Aucun autre code n'est nécessaire, il suffit d'ouvrir + la page dans un navigateur. + </p> + <p> + En cas échec, l'affichage ressemble à... + <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> + ...et si ça passe, on obtient... + <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> + Et si vous obtenez ça... + <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> + c'est qu'il vous manque le fichier <em>classes/Log.php</em> + qui pourrait ressembler à : +<pre> +<?php<strong> +class Log { + function Log($file_path) { + } + + function message() { + } +}</strong> +?> +</pre> + C'est largement plus sympathique d'écrire le code après le test. + Plus que sympatique même - cette technique s'appelle + "Développement Piloté par les Tests" ou + "Test Driven Development" en anglais. + </p> + <p> + Pour plus de renseignements sur le testeur, voyez la + <a href="unit_test_documentation.html">documentation pour les tests de régression</a>. + </p> + + <h2> +<a class="target" name="group"></a>Construire des groupes de tests</h2> + <p> + Il est peu probable que dans une véritable application on + ait uniquement besoin de passer un seul scénario de test. + Cela veut dire que nous avons besoin de grouper les + scénarios dans un script de test qui peut, si nécessaire, + lancer tous les tests de l'application. + </p> + <p> + Notre première étape est de créer un nouveau fichier appelé + <em>tests/all_tests.php</em> et d'y inclure le code suivant... +<pre> +<?php +<strong>require_once('simpletest/autorun.php');</strong> + +class AllTests extends <strong>TestSuite</strong> { + function AllTests() { + $this->TestSuite(<strong>'All tests'</strong>); + <strong>$this->addFile('log_test.php');</strong> + } +} +?> +</pre> + L'inclusion de "autorun" permettra à notre future suite + de tests d'être lancée juste en invoquant ce script. + </p> + <p> + La sous-classe <span class="new_code">TestSuite</span> doit chaîner + son constructeur. Cette limitation sera supprimée dans + les versions à venir. + </p> + <p> + The method <span class="new_code">TestSuite::addFile()</span> + will include the test case file and read any new classes + that are descended from <span class="new_code">SimpleTestCase</span>. + + Cette méthode <span class="new_code">TestSuite::addTestFile()</span> va + inclure le fichier de scénarios de test et lire parmi + toutes les nouvelles classes créées celles qui sont issues + de <span class="new_code">SimpleTestCase</span>. + <span class="new_code">UnitTestCase</span> est juste un exemple de classe dérivée + depuis <span class="new_code">SimpleTestCase</span> et vous pouvez créer les vôtres. + <span class="new_code">TestSuite::addFile()</span> peut aussi inclure d'autres suites. + </p> + <p> + La classe ne sera pas encore instanciée. + Quand la suite de tests est lancée, elle construira chaque instance + une fois le test atteint, et le détuira juste ensuite. + Cela veut dire que le constructeur n'est lancé qu'une fois avant + chaque initialisation de ce scénario de test et que le destructeur + est lui aussi lancé avant que le test suivant ne commence. + </p> + <p> + Il est commun de grouper des scénarios de test dans des super-classes + qui ne sont pas sensées être lancées, mais qui deviennent une classe de base + pour d'autres tests. + Pour que "autorun" fonctionne proprement les fichiers + des scénarios de test ne devraient pas lancer aveuglement + d'autres extensions de scénarios de test qui ne lanceraient pas + effectivement des tests. + Cela pourrait aboutir à un mauvais comptages des scénarios de test + pendant la procédure. + Pas vraiement un problème majeure, mais pour éviter cet inconvénient + il suffit de marquer vos classes de base comme <span class="new_code">abstract</span>. + SimpleTest ne lance pas les classes abstraites. Et si vous utilisez encore + PHP4 alors une directive <span class="new_code">SimpleTestOptions::ignore()</span> + dans votre fichier de scénario de test aura le même effet. + </p> + <p> + Par ailleurs, le fichier avec le scénario de test ne devrait pas + avoir été inclus ailleurs. Sinon aucun scénario de test + ne sera inclus à ce groupe. + Ceci pourrait se transformer en un problème plus grave : + si des fichiers ont déjà été inclus par PHP alors la méthode + <span class="new_code">TestSuite::addFile()</span> ne les détectera pas. + </p> + <p> + Pour afficher les résultats, il est seulement nécessaire + d'invoquer <em>tests/all_tests.php</em> à partir du serveur + web. + </p> + <p> + Pour plus de renseignements des groupes de tests, voyez le + <a href="group_test_documentation.html">documentation sur le groupement des tests</a>. + </p> + + <h2> +<a class="target" name="mock"></a>Utiliser les objets fantaisie</h2> + <p> + Avançons un peu plus dans le futur. + </p> + <p> + Supposons que notre class logging soit testée et terminée. + Supposons aussi que nous testons une autre classe qui ait + besoin d'écrire des messages de log, disons + <span class="new_code">SessionPool</span>. Nous voulons tester une méthode + qui ressemblera probablement à quelque chose comme... +<pre><strong> +class SessionPool { + ... + function logIn($username) { + ... + $this->_log->message('User $username logged in.'); + ... + } + ... +} +</strong> +</pre> + Avec le concept de "réutilisation de code" comme fil + conducteur, nous utilisons notre class <span class="new_code">Log</span>. Un + scénario de test classique ressemblera peut-être à... +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('../classes/log.php'); +<strong>require_once('../classes/session_pool.php');</strong> + +class <strong>TestOfSessionLogging</strong> extends UnitTestCase { + + function setUp() { + <strong>@unlink('/temp/test.log');</strong> + } + + function tearDown() { + <strong>@unlink('/temp/test.log');</strong> + } + + function testLoggingInIsLogged() { + <strong>$log = new Log('/temp/test.log'); + $session_pool = &new SessionPool($log); + $session_pool->logIn('fred');</strong> + $messages = file('/temp/test.log'); + $this->assertEqual($messages[0], "User fred logged in.<strong>\n</strong>"); + } +} +?> +</pre> + Nous expliquerons les méthodes <span class="new_code">setUp()</span> + et <span class="new_code">tearDown()</span> plus tard. + </p> + <p> + Le design de ce scénario de test n'est pas complètement + mauvais, mais on peut l'améliorer. Nous passons du temps à + tripoter les fichiers de log qui ne font pas partie de + notre test. + Pire, nous avons créé des liens de proximité + entre la classe <span class="new_code">Log</span> et ce test. Que se + passerait-il si nous n'utilisions plus de fichiers, mais la + bibliothèque <em>syslog</em> à la place ? + + Cela veut dire que notre test <span class="new_code">TestOfSessionLogging</span> + enverra un échec alors même qu'il ne teste pas Logging. + </p> + <p> + Il est aussi fragile sur des petites retouches. Avez-vous + remarqué le retour chariot supplémentaire à la fin du + message ? A-t-il été ajouté par le loggueur ? Et si il + ajoutait aussi un timestamp ou d'autres données ? + </p> + <p> + L'unique partie à tester réellement est l'envoi d'un + message précis au loggueur. + Nous pouvons réduire le couplage en + créant une fausse classe de logging : elle ne fait + qu'enregistrer le message pour le test, mais ne produit + aucun résultat. Sauf qu'elle doit ressembler exactement à + l'original. + </p> + <p> + Si l'objet fantaisie n'écrit pas dans un fichier alors nous + nous épargnons la suppression du fichier avant et après le + test. Nous pourrions même nous épargner quelques lignes de + code supplémentaires si l'objet fantaisie pouvait exécuter + l'assertion. + <p> + </p> + Trop beau pour être vrai ? Pas vraiement on peut créer un tel + objet très facilement... +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('../classes/log.php'); +require_once('../classes/session_pool.php'); + +<strong>Mock::generate('Log');</strong> + +class TestOfSessionLogging extends UnitTestCase { + + function testLoggingInIsLogged() {<strong> + $log = &new MockLog(); + $log->expectOnce('message', array('User fred logged in.'));</strong> + $session_pool = &new SessionPool(<strong>$log</strong>); + $session_pool->logIn('fred'); + } +} +?> +</pre> + L'appel <span class="new_code">Mock::generate()</span> a généré + une nouvelle classe appelé <span class="new_code">MockLog</span>. + Cela ressemble à un clone identique, sauf que nous pouvons + y adjoindre du code de test. + C'est ce que fait <span class="new_code">expectOnce()</span>. + Cela dit que si <span class="new_code">message()</span> m'est appelé, + il a intérêt à l'être avec le paramètre + "User fred logged in.". + </p> + <p> + L'appel <span class="new_code">tally()</span> est nécessaire pour annoncer à + l'objet fantaisie qu'il n'y aura plus d'appels ultérieurs. + Sans ça l'objet fantaisie pourrait attendre pendant une + éternité l'appel de la méthode sans jamais prévenir le + scénario de test. Les autres tests sont déclenchés + automatiquement quand l'appel à <span class="new_code">message()</span> est + invoqué sur l'objet <span class="new_code">MockLog</span> par le code + <span class="new_code">SessionPool::logIn()</span>. + L'appel <span class="new_code">mock</span> va déclencher une comparaison des + paramètres et ensuite envoyer le message "pass" ou "fail" + au test pour l'affichage. Des jokers peuvent être inclus + pour ne pas avoir à tester tous les paramètres d'un appel + alors que vous ne souhaitez qu'en tester un. + </p> + <p> + Les objets fantaisie dans la suite SimpleTest peuvent avoir + un ensemble de valeurs de sortie arbitraires, des séquences + de sorties, des valeurs de sortie sélectionnées à partir + des arguments d'entrée, des séquences de paramètres + attendus et des limites sur le nombre de fois qu'une + méthode peut être invoquée. + </p> + <p> + Pour que ce test fonctionne la librairie avec les objets + fantaisie doit être incluse dans la suite de tests, par + exemple dans <em>all_tests.php</em>. + </p> + <p> + Pour plus de renseignements sur les objets fantaisie, voyez le + <a href="mock_objects_documentation.html">documentation sur les objets fantaisie</a>. + </p> + + <h2> +<a class="target" name="web"></a>Tester une page web</h2> + <p> + Une des exigences des sites web, c'est qu'ils produisent + des pages web. Si vous construisez un projet de A à Z et + que vous voulez intégrer des tests au fur et à mesure alors + vous voulez un outil qui puisse effectuer une navigation + automatique et en examiner le résultat. C'est le boulot + d'un testeur web. + </p> + <p> + Effectuer un test web via SimpleTest reste assez primitif : + il n'y a pas de javascript par exemple. + La plupart des autres opérations d'un navigateur sont simulées. + </p> + <p> + Pour vous donner une idée, voici un exemple assez trivial : + aller chercher une page web, + à partir de là naviguer vers la page "about" + et finalement tester un contenu déterminé par le client. +<pre> +<?php +require_once('simpletest/autorun.php'); +<strong>require_once('simpletest/web_tester.php');</strong> + +class TestOfAbout extends <strong>WebTestCase</strong> { + function testOurAboutPageGivesFreeReignToOurEgo() { + <strong>$this->get('http://test-server/index.php'); + $this->click('About'); + $this->assertTitle('About why we are so great'); + $this->assertText('We are really great');</strong> + } +} +?> +</pre> + Avec ce code comme test de recette, vous pouvez vous + assurer que le contenu corresponde toujours aux + spécifications à la fois des développeurs et des autres + parties prenantes au projet. + </p> + <p> + Vous pouvez aussi naviguer à travers des formulaires... +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('simpletest/web_tester.php'); + +class TestOfRankings extends WebTestCase { + function testWeAreTopOfGoogle() { + $this->get('http://google.com/'); + $this->setField('q', 'simpletest'); + $this->click("I'm Feeling Lucky"); + $this->assertTitle('SimpleTest - Unit Testing for PHP'); + } +} +?> +</pre> + ...même si cela pourrait constituer une violation + des documents juridiques de Google(tm). + </p> + <p> + Pour plus de renseignements sur comment tester une page web, voyez la + <a href="web_tester_documentation.html">documentation sur tester des scripts web</a>. + </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> + References and related information... + <ul> +<li> + <a href="https://sourceforge.net/project/showfiles.php?group_id=76550&release_id=153280">Télécharger PHP SimpleTest</a> + depuis <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + L'<a href="http://simpletest.org/api/">API de SimpleTest pour développeur</a> + donne tous les détails sur les classes et assertions existantes. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/mock_objects_documentation.html b/3rdparty/simpletest/docs/fr/mock_objects_documentation.html new file mode 100644 index 00000000000..97e2c86ee73 --- /dev/null +++ b/3rdparty/simpletest/docs/fr/mock_objects_documentation.html @@ -0,0 +1,933 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : les objets fantaise</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur les objets fantaisie</h1> + This page... + <ul> +<li> + <a href="#what">Que sont les objets fantaisie ?</a> + </li> +<li> + <a href="#creation">Créer des objets fantaisie</a>. + </li> +<li> + <a href="#expectations">Les objets fantaisie en tant que critiques</a> avec les attentes. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="what"></a>Que sont les objets fantaisie ?</h2> + <p> + Les objets fantaisie - ou "mock objects" en anglais - + ont deux rôles pendant un scénario de test : acteur et critique. + </p> + <p> + Le comportement d'acteur est celui de simuler + des objets difficiles à initialiser ou trop consommateurs + en temps pendant un test. + Le cas classique est celui de la connexion à une base de données. + Mettre sur pied une base de données de test au lancement + de chaque test ralentirait considérablement les tests + et en plus exigerait l'installation d'un moteur + de base de données ainsi que des données sur la machine de test. + Si nous pouvons simuler la connexion + et renvoyer des données à notre guise + alors non seulement nous gagnons en pragmatisme + sur les tests mais en sus nous pouvons nourrir + notre base avec des données falsifiées + et voir comment il répond. Nous pouvons + simuler une base de données en suspens ou + d'autres cas extrêmes sans avoir à créer + une véritable panne de base de données. + En d'autres termes nous pouvons gagner + en contrôle sur l'environnement de test. + </p> + <p> + Si les objets fantaisie ne se comportaient que comme + des acteurs alors on les connaîtrait sous le nom de + <a href="server_stubs_documentation.html">bouchons serveur</a>. + Il s'agissait originairement d'un patron de conception + identifié par Robert Binder (<a href="">Testing + object-oriented systems</a>: models, patterns, and tools, + Addison-Wesley) en 1999. + </p> + <p> + Un bouchon serveur est une simulation d'un objet ou d'un composant. + Il doit remplacer exactement un composant dans un système + en vue d'effectuer des tests ou un prototypage, + tout en restant ultra-léger. + Il permet aux tests de s'exécuter plus rapidement, ou + si la classe simulée n'a pas encore été écrite, + de se lancer tout court. + </p> + <p> + Cependant non seulement les objets fantaisie jouent + un rôle (en fournissant à la demande les valeurs requises) + mais en plus ils sont aussi sensibles aux messages qui + leur sont envoyés (par le biais d'attentes). + En posant les paramètres attendus d'une méthode + ils agissent comme des gardiens : + un appel sur eux doit être réalisé correctement. + Si les attentes ne sont pas atteintes ils nous épargnent + l'effort de l'écriture d'une assertion de test avec + échec en réalisant cette tâche à notre place. + </p> + <p> + Dans le cas d'une connexion à une base de données + imaginaire ils peuvent tester si la requête, disons SQL, + a bien été formé par l'objet qui utilise cette connexion. + Mettez-les sur pied avec des attentes assez précises + et vous verrez que vous n'aurez presque plus d'assertion à écrire manuellement. + </p> + + <h2> +<a class="target" name="creation"></a>Créer des objets fantaisie</h2> + <p> + Tout ce dont nous avons besoin est une classe existante ou une interface, + par exemple une connexion à la base de données qui ressemblerait à... +<pre> +<strong>class DatabaseConnection { + function DatabaseConnection() { } + function query($sql) { } + function selectQuery($sql) { } +}</strong> +</pre> + Pour en créer sa version fantaisie nous devons juste + lancer le générateur... +<pre> +require_once('simpletest/autorun.php'); +require_once('database_connection.php'); + +<strong>Mock::generate('DatabaseConnection');</strong> +</pre> + Ce code génère une classe clone appelée <span class="new_code">MockDatabaseConnection</span>. + Cette nouvelle classe lui ressemble en tout point, + sauf qu'elle ne fait rien du tout. + </p> + <p> + Cette nouvelle classe est génératlement + une sous-classe de <span class="new_code">DatabaseConnection</span>. + Malheureusement, il n'y as aucun moyen de créer une version fantaisie + d'une classe avec une méthode <span class="new_code">final</span> sans avoir + une version fonctionnelle de cette méthode. + Ce n'est pas pas très satisfaisant. + Si la cible est une interface ou si les méthodes <span class="new_code">final</span> + existent dans la classe cible, alors une toute nouvelle classe + est créée, elle implémente juste les même interfaces. + Si vous essayer de faire passer cette classe à travers un indice de type + qui spécifie le véritable nom de l'ancienne classe, alors il échouera. + Du code qui forcerait un indice de type tout en utilisant + des méthodes <span class="new_code">final</span> ne pourrait probablement pas être + testé efficacement avec des objets fantaisie. + </p> + <p> + Si vous voulez voir le code généré, il suffit de faire un <span class="new_code">print</span> + de la sortie de <span class="new_code">Mock::generate()</span>. + VOici le code généré pour la classe <span class="new_code">DatabaseConnection</span> + à la place de son interface... +<pre> +class MockDatabaseConnection extends DatabaseConnection { + public $mock; + protected $mocked_methods = array('databaseconnection', 'query', 'selectquery'); + + function MockDatabaseConnection() { + $this->mock = new SimpleMock(); + $this->mock->disableExpectationNameChecks(); + } + ... + function DatabaseConnection() { + $args = func_get_args(); + $result = &$this->mock->invoke("DatabaseConnection", $args); + return $result; + } + function query($sql) { + $args = func_get_args(); + $result = &$this->mock->invoke("query", $args); + return $result; + } + function selectQuery($sql) { + $args = func_get_args(); + $result = &$this->mock->invoke("selectQuery", $args); + return $result; + } +} +</pre> + Votre sortie dépendra quelque peu de votre version précise de SimpleTest. + </p> + <p> + En plus des méthodes d'origine de la classe, vous en verrez d'autres + pour faciliter les tests. + Nous y reviendrons. + </p> + <p> + Nous pouvons désormais créer des instances de + cette nouvelle classe à l'intérieur même de notre scénario de test... +<pre> +require_once('simpletest/autorun.php'); +require_once('database_connection.php'); + +Mock::generate('DatabaseConnection'); + +class MyTestCase extends UnitTestCase { + + function testSomething() { + <strong>$connection = new MockDatabaseConnection();</strong> + } +} +</pre> + La version fantaisie contient toutles méthodes de l'originale. + En outre, tous les indices de type seront préservés. + Dison que nos méthodes de requête attend un objet <span class="new_code">Query</span>... +<pre> +<strong>class DatabaseConnection { + function DatabaseConnection() { } + function query(Query $query) { } + function selectQuery(Query $query) { } +}</strong> +</pre> + Si nous lui passons le mauvais type d'objet + ou même pire un non-objet... +<pre> +class MyTestCase extends UnitTestCase { + + function testSomething() { + $connection = new MockDatabaseConnection(); + $connection->query('insert into accounts () values ()'); + } +} +</pre> + ...alors le code renverra une violation de typage, + exactement comme on aurait pû s'y attendre + avec la classe d'origine. + </p> + <p> + Si la version fantaisie implémente bien toutes les méthodes + de l'originale, elle renvoit aussi systématiquement <span class="new_code">null</span>. + Et comme toutes les méthodes qui renvoient toujours <span class="new_code">null</span> + ne sont pas très utiles, nous avons besoin de leur faire dire + autre chose... + </p> + + <h2> +<a class="target" name="bouchon"></a>Objets fantaisie en action</h2> + <p> + Changer le <span class="new_code">null</span> renvoyé par la méthode fantaisie + en autre chose est assez facile... +<pre> +<strong>$connection->returns('query', 37)</strong> +</pre> + Désormais à chaque appel de <span class="new_code">$connection->query()</span> + nous obtenons un résultat de 37. + Il n'y a rien de particulier à cette valeur de 37. + Cette valeur de retour peut être aussi compliqué que nécessaire. + </p> + <p> + Ici les paramètres ne sont pas significatifs, + nous aurons systématiquement la même valeur en retour + une fois initialisés de la sorte. + Cela pourrait ne pas ressembler à une copie convaincante + de notre connexion à la base de données, mais pour + la demi-douzaine de lignes de code de notre méthode de test + c'est généralement largement assez. + </p> + <p> + Sauf que les choses ne sont pas toujours si simples. + Les itérateurs sont un problème récurrent, si par exemple + renvoyer systématiquement la même valeur entraine + une boucle infinie dans l'objet testé. + Pour ces cas-là, nous avons besoin d'une séquence de valeurs. + Supposons que nous avons un itérateur simple qui ressemble à... +<pre> +class Iterator { + function Iterator() { } + function next() { } +} +</pre> + Il s'agit là de l'itérateur le plus basique que nous puissions imaginer. + Supponsons que cet itérateur ne renvoit que du texte + jusqu'à ce qu'il atteigne la fin et qu'il renvoie alors un false, + nous pouvons le simuler avec... +<pre> +Mock::generate('Iterator'); + +class IteratorTest extends UnitTestCase() { + + function testASequence() {<strong> + $iterator = new MockIterator(); + $iterator->returns('next', false); + $iterator->returnsAt(0, 'next', 'First string'); + $iterator->returnsAt(1, 'next', 'Second string');</strong> + ... + } +} +</pre> + Quand <span class="new_code">next()</span> est appelé par le <span class="new_code">MockIterator</span> + il commencera par renvoyer "First string", + au deuxième passage "Second string" sera renvoyé + et sur n'importe quel autre appel <span class="new_code">false</span> sera renvoyé + à son tour. + Les valeurs renvoyées les unes après les autres auront la priorité + sur la valeur constante. + Cette dernière est la valeur par défaut en quelque sorte. + </p> + <p> + Une autre situation délicate serait une opération + <span class="new_code">get()</span> surchargée. + Un exemple serait un conteneur d'information avec des pairs clef/valeur. + Nous partons cette fois d'une classe de configuration telle... +<pre> +class Configuration { + function Configuration() { ... } + function get($key) { ... } +} +</pre> + C'est une situation courante pour utiliser des objets fantaisie, + étant donné que la véritable configuration sera différente + d'une machine à l'autre et parfois même d'un test à l'autre. + Cependant un problème apparaît quand toutes les données passent + par la méthode <span class="new_code">get()</span> et que nous souhaitons + quand même des résultats différents pour des clefs différentes. + Par chance les objets fantaisie ont un système de filtre... +<pre> +<strong>$config = &new MockConfiguration(); +$config->returns('get', 'primary', array('db_host')); +$config->returns('get', 'admin', array('db_user')); +$config->returns('get', 'secret', array('db_password'));</strong> +</pre> + Le dernier paramètre est une liste d'arguements + pour vérifier une correspondance. + Dans ce cas, nous essayons de faire correspondre un argument + qui se trouve être la clef de recherche. + Désormais quand l'objet fantaisie voit + sa méthode <span class="new_code">get()</span> invoquée... +<pre> +$config->get('db_user') +</pre> + ...il renverra "admin". + Il trouve cette valeur en essayant de faire correspondre + l'argument reçu à ceux de ses propres listes : dès qu'une + correspondance complète est trouvé, il s'arrête. + </p> + <p> + Vous pouvez préciser un argument par défaut via... +<pre><strong> +$config->returns('get', false, array('*'));</strong> +</pre> + Ce n'est pas la même chose que de définir la valeur renvoyée + sans aucun arguement... +<pre><strong> +$config->returns('get', false);</strong> +</pre> + Dans le premier cas, il acceptera n'importe quel argument, + mais il en faut au moins un. + Dans le deuxième cas, n'importe quel nombre d'arguments + fera l'affaire and il agit comme un attrape-tout après + toutes les autres vérifications. + Notez que si - dans le premier cas - nous ajoutons + d'autres options avec paramètre unique après le joker, + alors elle seront ignorés puisque le joker fera + la première correspondance. + Avec des listes complexes de paramètres, l'ordre devient + important au risque de voir la correspondance souhaitée + masqué par un joker apparu plus tôt. + Déclarez les plus spécifiques d'abord si vous n'êtes pas sûr. + </p> + <p> + Il y a des moments où vous souhaitez qu'une référence + bien spécifique soit servie par l'objet fantaisie plutôt + qu'une copie. + C'est plutôt rare pour dire le moins, mais vous pourriez + être en train de simuler un conteneur qui détiendrait + des primitives, tels des chaînes de caractères. + Par exemple. +<pre> +class Pad { + function Pad() { } + function &note($index) { } +} +</pre> + Dans ce cas, vous pouvez définir une référence dans la liste + des valeurs retournées par l'objet fantaisie... +<pre> +function testTaskReads() { + $note = 'Buy books'; + $pad = new MockPad(); + $vector-><strong>returnsByReference(</strong>'note', $note, array(3)<strong>)</strong>; + $task = new Task($pad); + ... +} +</pre> + Avec cet assemblage vous savez qu'à chaque fois + que <span class="new_code">$pad->note(3)</span> est appelé + il renverra toujours la même <span class="new_code">$note</span>, + même si celle-ci est modifiée. + </p> + <p> + Ces trois facteurs, timing, paramètres et références, + peuvent être combinés orthogonalement. + Par exemple... +<pre> +$buy_books = 'Buy books'; +$write_code = 'Write code'; +$pad = new MockPad(); +$vector-><strong>returnsByReferenceAt(0, 'note', $buy_books, array('*', 3));</strong> +$vector-><strong>returnsByReferenceAt(1, 'note', $write_code, array('*', 3));</strong> +</pre> + Cela renverra une référence à <span class="new_code">$buy_books</span> et + ensuite à <span class="new_code">$write_code</span>, mais seuleent si deux paramètres + sont utilisés, le deuxième devant être l'entier 3. + Cela devrait couvrir la plupart des situations. + </p> + <p> + Un dernier cas délicat reste : celui d'un objet créant + un autre objet, plus connu sous le patron de conception "fabrique" + (ou "factory"). + Supponsons qu'à la réussite d'une requête à + notre base de données imaginaire, un jeu d'enregistrements + est renvoyé sous la forme d'un itérateur, où chaque appel + au <span class="new_code">next()</span> sur notre itérateur donne une ligne + avant de s'arrêtre avec un false. + Cela semble à un cauchemar à simuler, alors qu'en fait un objet + fantaisie peut être créé avec les mécansimes ci-dessus... +<pre> +Mock::generate('DatabaseConnection'); +Mock::generate('ResultIterator'); + +class DatabaseTest extends UnitTestCase { + + function testUserFinderReadsResultsFromDatabase() {<strong> + $result = new MockResultIterator(); + $result->returns('next', false); + $result->returnsAt(0, 'next', array(1, 'tom')); + $result->returnsAt(1, 'next', array(3, 'dick')); + $result->returnsAt(2, 'next', array(6, 'harry')); + + $connection = new MockDatabaseConnection(); + $connection->returns('selectQuery', $result);</strong> + + $finder = new UserFinder(<strong>$connection</strong>); + $this->assertIdentical( + $finder->findNames(), + array('tom', 'dick', 'harry')); + } +} +</pre> + Désormais ce n'est que si notre <span class="new_code">$connection</span> + est appelée par la méthode <span class="new_code">query()</span> + que sera retourné le <span class="new_code">$result</span>, + lui-même s'arrêtant au troisième appel + à <span class="new_code">next()</span>. + Ce devrait être suffisant comme information + pour que notre classe <span class="new_code">UserFinder</span>, + la classe effectivement testée ici, + fasse son boulot. + Un test très précis et toujours pas + de base de données en vue. + </p> + <p> + Nous pourrsion affiner ce test encore plus + en insistant pour que la bonne requête + soit envoyée... +<pre> +$connection->returns('selectQuery', $result, array(<strong>'select name, id from people'</strong>)); +</pre> + Là, c'est une mauvaise idée. + </p> + <p> + Niveau objet, nous avons un <span class="new_code">UserFinder</span> + qui parle à une base de données à travers une interface géante - + l'ensemble du SQL. + Imaginez si nous avions écrit un grand nombre de tests + qui dépendrait désormais de cette requête SQL précise. + Ces requêtes pourraient changer en masse pour tout un tas + de raisons non liés à ce test spécifique. + Par exemple, la règle pour les quotes pourrait changer, + un nom de table pourrait évoluer, une table de liaison pourrait + être ajouté, etc. + Cela entrainerait une ré-écriture de tous les tests à chaque fois + qu'un remaniement est fait, alors même que le comportement lui + n'a pas bougé. + Les tests sont censés aider au remaniement, pas le bloquer. + Pour ma part, je préfère avoir une suite de tests qui passent + quand je fais évoluer le nom des tables. + </p> + <p> + Et si vous voulez une règle, c'est toujours mieux de ne pas + créer un objet fantaisie sur une grosse interface. + </p> + <p> + Par contrast, voici le test complet... +<pre> +class DatabaseTest extends UnitTestCase {<strong> + function setUp() { ... } + function tearDown() { ... }</strong> + + function testUserFinderReadsResultsFromDatabase() { + $finder = new UserFinder(<strong>new DatabaseConnection()</strong>); + $finder->add('tom'); + $finder->add('dick'); + $finder->add('harry'); + $this->assertIdentical( + $finder->findNames(), + array('tom', 'dick', 'harry')); + } +} +</pre> + Ce test est immunisé contre le changement de schéma. + Il échouera uniquement si vous changez la fonctionnalité, + ce qui correspond bien à ce qu'un test doit faire. + </p> + <p> + Il faut juste faire attention à ces méthodes <span class="new_code">setUp()</span> + et <span class="new_code">tearDown()</span> que nous avons survolé pour l'instant. + Elles doivent vider les tables de la base de données + et s'assurer que le schéma est bien défini. + Cela peut se engendrer un peu de travail supplémentaire, + mais d'ordinaire ce type de code existe déjà - à commencer pour + le déploiement. + </p> + <p> + Il y a au moins un endroit où vous aurez besoin d'objets fantaisie : + c'est la simulation des erreurs. + Exemple, la base de données tombe pendant que <span class="new_code">UserFinder</span> + fait son travail. Le <span class="new_code">UserFinder</span> se comporte-t-il bien ? +<pre> +class DatabaseTest extends UnitTestCase { + + function testUserFinder() { + $connection = new MockDatabaseConnection();<strong> + $connection->throwOn('selectQuery', new TimedOut('Ouch!'));</strong> + $alert = new MockAlerts();<strong> + $alert->expectOnce('notify', 'Database is busy - please retry');</strong> + $finder = new UserFinder($connection, $alert); + $this->assertIdentical($finder->findNames(), array()); + } +} +</pre> + Nous avons transmis au <span class="new_code">UserFinder</span> + un objet <span class="new_code">$alert</span>. + Il va transmettre un certain nombre de belles notifications + à l'interface utilisatuer en cas d'erreur. + Nous préfèrerions éviter de saupoudrer notre code avec + des commandes <span class="new_code">print</span> codées en dur si nous pouvons + l'éviter. + Emballer les moyens de sortie veut dire que nous pouvons utiliser + ce code partout. Et cela rend notre code plus facile. + </p> + <p> + Pour faire passer ce test, le finder doit écrire un message sympathique + et compréhensible à l'<span class="new_code">$alert</span>, plutôt que de propager + l'exception. Jusque là, tout va bien. + </p> + <p> + Comment faire en sorte que la <span class="new_code">DatabaseConnection</span> fantaisie + soulève une exception ? + Nous la générons avec la méthode <span class="new_code">throwOn</span> sur l'objet fantaisie. + </p> + <p> + Enfin, que se passe-t-il si la méthode voulue pour la simulation + n'existe pas encore ? + Si vous définissez une valeur de retour sur une méthode absente, + alors SimpleTest vous répondra avec une erreur. + Et si vous utilisez <span class="new_code">__call()</span> pour simuler + des méthodes dynamiques ? + </p> + <p> + Les objets avec des interfaces dynamiques, avec <span class="new_code">__call</span>, + peuvent être problématiques dans l'implémentation courante + des objets fantaisie. + Vous pouvez en créer un autour de la méthode <span class="new_code">__call()</span> + mais c'est très laid. + Et pourquoi un test devrait connaître quelque chose avec un niveau + si bas dans l'implémentation. Il n'a besoin que de simuler l'appel. + </p> + <p> + Il y a bien moyen de contournement : ajouter des méthodes complémentaires + à l'objet fantaisie à la génération. +<pre> +<strong>Mock::generate('DatabaseConnection', 'MockDatabaseConnection', array('setOptions'));</strong> +</pre> + Dans une longue suite de tests cela pourrait entraîner des problèmes, + puisque vous avez probablement déjà une version fantaisie + de la classe appellée <span class="new_code">MockDatabaseConnection</span> + sans les méthodes complémentaires. + Le générateur de code ne générera pas la version fantaisie de la classe + s'il en existe déjà une version avec le même nom. + Il vous deviendra impossible de déterminer où est passée votre méthode + si une autre définition a été lancé au préalable. + </p> + <p> + Pour pallier à ce problème, SimpleTest vous permet de choisir + n'importe autre nom pour la nouvelle classe au moment même où + vous ajouter les méthodes complémentaires. +<pre> +Mock::generate('DatabaseConnection', <strong>'MockDatabaseConnectionWithOptions'</strong>, array('setOptions')); +</pre> + Ici l'objet fantaisie se comportera comme si + <span class="new_code">setOptions()</span> existait bel et bien + dans la classe originale. + </p> + <p> + Les objets fantaisie ne peuvent être utilisés qu'à l'intérieur + des scénarios de test, étant donné qu'à l'apparition d'une attente + ils envoient des messages directement au scénario de test courant. + Les créer en dehors d'un scénario de test entraînera une erreur + de run time quand une attente est déclenchée et qu'il n'y a pas + de scénario de test en cours pour recevoir le message. + Nous pouvons désormais couvrir ces attentes. + </p> + + <h2> +<a class="target" name="expectations"></a>Objets fantaisie en tant que critiques</h2> + <p> + Même si les bouchons serveur isolent vos tests des perturbations + du monde réel, ils n'apportent que le moitié des bénéfices possibles. + Vous pouvez obtenir une classe de test qui reçoive les bons messages, + mais cette nouvelle classe envoie-t-elle les bons ? + Le tester peut devenir très bordélique sans + une librairie d'objets fantaise. + </p> + <p> + Voici un exemple, prenons une classe <span class="new_code">PageController</span> + toute simple qui traitera un formulaire de paiement + par carte bleue... +<pre> +class PaymentForm extends PageController { + function __construct($alert, $payment_gateway) { ... } + function makePayment($request) { ... } +} +</pre> + Cette classe a besoin d'un <span class="new_code">PaymentGateway</span> + pour parler concrètement à la banque. + Il utilise aussi un objet <span class="new_code">Alert</span> + pour gérer les erreurs. + Cette dernière classe parle à la page ou au template. + Elle est responsable de l'affichage du message d'erreur + et de la mise en valeur de tout champ du formulaire + qui serait incorrecte. + </p> + <p> + Elle pourrait ressembler à... +<pre> +class Alert { + function warn($warning, $id) { + print '<div class="warning">' . $warning . '</div>'; + print '<style type="text/css">#' . $id . ' { background-color: red }</style>'; + } +} +</pre> + </p> + <p> + Portons notre attention à la méthode <span class="new_code">makePayment()</span>. + Si nous n'inscrivons pas un numéro "CVV2" (celui à trois + chiffre au dos de la carte bleue), nous souhaitons afficher + une erreur plutôt que d'essayer de traiter le paiement. + En mode test... +<pre> +<?php +require_once('simpletest/autorun.php'); +require_once('payment_form.php'); +Mock::generate('Alert'); +Mock::generate('PaymentGateway'); + +class PaymentFormFailuresShouldBeGraceful extends UnitTestCase { + + function testMissingCvv2CausesAlert() { + $alert = new MockAlert(); + <strong>$alert->expectOnce( + 'warn', + array('Missing three digit security code', 'cvv2'));</strong> + $controller = new PaymentForm(<strong>$alert</strong>, new MockPaymentGateway()); + $controller->makePayment($this->requestWithMissingCvv2()); + } + + function requestWithMissingCvv2() { ... } +} +?> +</pre> + Première question : où sont passés les assertions ? + </p> + <p> + L'appel à <span class="new_code">expectOnce('warn', array(...))</span> annonce + à l'objet fantaisie qu'il faut s'attendre à un appel à <span class="new_code">warn()</span> + avant la fin du test. + Quand il débouche sur l'appel à <span class="new_code">warn()</span>, il vérifie + les arguments. Si ceux-ci ne correspondent pas, alors un échec + est généré. Il échouera aussi si la méthode n'est jamais appelée. + </p> + <p> + Non seulement le test ci-dessus s'assure que <span class="new_code">warn</span> + a bien été appelé, mais en plus qu'il a bien reçu la chaîne + de caractère "Missing three digit security code" + et même le tag "cvv2". + L'équivalent de <span class="new_code">assertIdentical()</span> est appliqué + aux deux champs quand les paramètres sont comparés. + </p> + <p> + Si le contenu du message vous importe peu, surtout dans le cas + d'une interface utilisateur qui change régulièrement, + nous pouvons passer ce paramètre avec l'opérateur "*"... +<pre> +class PaymentFormFailuresShouldBeGraceful extends UnitTestCase { + + function testMissingCvv2CausesAlert() { + $alert = new MockAlert(); + $alert->expectOnce('warn', array(<strong>'*'</strong>, 'cvv2')); + $controller = new PaymentForm($alert, new MockPaymentGateway()); + $controller->makePayment($this->requestWithMissingCvv2()); + } + + function requestWithMissingCvv2() { ... } +} +</pre> + Nous pouvons même rendre le test encore moins spécifique + en supprimant complètement la liste des paramètres... +<pre> +function testMissingCvv2CausesAlert() { + $alert = new MockAlert(); + <strong>$alert->expectOnce('warn');</strong> + $controller = new PaymentForm($alert, new MockPaymentGateway()); + $controller->makePayment($this->requestWithMissingCvv2()); +} +</pre> + Ceci vérifiera uniquement si la méthode a été appelé, + ce qui est peut-être un peu drastique dans ce cas. + Plus tard, nous verrons comment alléger les attentes + plus précisement. + </p> + <p> + Des tests sans assertions peuvent être à la fois compacts + et très expressifs. Parce que nous interceptons l'appel + sur le chemin de l'objet, ici de classe <span class="new_code">Alert</span>, + nous évitons de tester l'état par la suite. + Cela évite les assertions dans les tests, mais aussi + l'obligation d'ajouter des accesseurs uniquement + pour les tests dans le code original. + Si vous en arrivez à ajouter des accesseurs de ce type, + on parle alors de "state based testing" dans le jargon + ("test piloté par l'état"), + il est probablement plus que temps d'utiliser + des objets fantaisie dans vos tests. + On peut alors parler de "behaviour based testing" + (ou "test piloté par le comportement") : + c'est largement mieux ! + </p> + <p> + Ajoutons un autre test. + Assurons nous que nous essayons même pas un paiement sans CVV2... +<pre> +class PaymentFormFailuresShouldBeGraceful extends UnitTestCase { + + function testMissingCvv2CausesAlert() { ... } + + function testNoPaymentAttemptedWithMissingCvv2() { + $payment_gateway = new MockPaymentGateway(); + <strong>$payment_gateway->expectNever('pay');</strong> + $controller = new PaymentForm(new MockAlert(), $payment_gateway); + $controller->makePayment($this->requestWithMissingCvv2()); + } + + ... +} +</pre> + Vérifier une négation peut être très difficile + dans les tests, mais <span class="new_code">expectNever()</span> + rend l'opération très facile heureusement. + </p> + <p> + <span class="new_code">expectOnce()</span> et <span class="new_code">expectNever()</span> sont + suffisants pour la plupart des tests, mais + occasionnellement vous voulez tester plusieurs évènements. + D'ordinaire pour des raisons d'usabilité, nous souhaitons + que tous les champs manquants du formulaire soient + mis en relief, et pas uniquement le premier. + Cela veut dire que nous devrions voir de multiples appels + à <span class="new_code">Alert::warn()</span>, pas juste un... +<pre> +function testAllRequiredFieldsHighlightedOnEmptyRequest() { + $alert = new MockAlert();<strong> + $alert->expectAt(0, 'warn', array('*', 'cc_number')); + $alert->expectAt(1, 'warn', array('*', 'expiry')); + $alert->expectAt(2, 'warn', array('*', 'cvv2')); + $alert->expectAt(3, 'warn', array('*', 'card_holder')); + $alert->expectAt(4, 'warn', array('*', 'address')); + $alert->expectAt(5, 'warn', array('*', 'postcode')); + $alert->expectAt(6, 'warn', array('*', 'country')); + $alert->expectCallCount('warn', 7);</strong> + $controller = new PaymentForm($alert, new MockPaymentGateway()); + $controller->makePayment($this->requestWithMissingCvv2()); +} +</pre> + Le compteur dans <span class="new_code">expectAt()</span> précise + le nombre de fois que la méthode a déjà été appelée. + Ici nous vérifions que chaque champ sera bien mis en relief. + </p> + <p> + Notez que nous sommes forcé de tester l'ordre en même temps. + SimpleTest n'a pas encore de moyen pour éviter cela, + mais dans une version future ce sera corrigé. + </p> + <p> + Voici la liste complètes des attentes + que vous pouvez préciser sur une objet fantaisie + dans <a href="http://simpletest.org/">SimpleTest</a>. + Comme pour les assertions, ces méthodes prennent en option + un message d'erreur. + <table> + <thead><tr> +<th>Attente</th> +<th>Description</th> +</tr></thead> + <tbody> + <tr> + <td><span class="new_code">expect($method, $args)</span></td> + <td>Les arguements doivent correspondre si appelés</td> + </tr> + <tr> + <td><span class="new_code">expectAt($timing, $method, $args)</span></td> + <td>Les arguements doiven correspondre si appelés lors du passage numéro <span class="new_code">$timing</span> +</td> + </tr> + <tr> + <td><span class="new_code">expectCallCount($method, $count)</span></td> + <td>La méthode doit être appelée exactement <span class="new_code">$count</span> fois</td> + </tr> + <tr> + <td><span class="new_code">expectMaximumCallCount($method, $count)</span></td> + <td>La méthode ne doit pas être appelée plus de <span class="new_code">$count</span> fois</td> + </tr> + <tr> + <td><span class="new_code">expectMinimumCallCount($method, $count)</span></td> + <td>La méthode ne doit pas être appelée moins de <span class="new_code">$count</span> fois</td> + </tr> + <tr> + <td><span class="new_code">expectNever($method)</span></td> + <td>La méthode ne doit jamais être appelée</td> + </tr> + <tr> + <td><span class="new_code">expectOnce($method, $args)</span></td> + <td>La méthode ne doit être appelée qu'une seule fois et avec les arguments (en option)</td> + </tr> + <tr> + <td><span class="new_code">expectAtLeastOnce($method, $args)</span></td> + <td>La méthode doit être appelée au moins une seule fois et toujours avec au moins un des arguments attendus</td> + </tr> + </tbody> + </table> + Où les paramètres sont... + <dl> + <dt class="new_code">$method</dt> + <dd> + Le nom de la méthode, sous la forme d'une chaîne de caractères, + à laquelle il faut appliquer la condition. + </dd> + <dt class="new_code">$args</dt> + <dd> + Les argumetns sous la forme d'une liste. + Les jokers peuvent être inclus de la même manière + que pour <span class="new_code">setReturn()</span>. + Cet argument est optionnel pour <span class="new_code">expectOnce()</span> + et <span class="new_code">expectAtLeastOnce()</span>. + </dd> + <dt class="new_code">$timing</dt> + <dd> + La seule marque dans le temps pour tester la condition. + Le premier appel commence à zéro et le comptage se fait + séparement sur chaque méthode. + </dd> + <dt class="new_code">$count</dt> + <dd>Le nombre d'appels attendu.</dd> + </dl> + </p> + <p> + Si vous n'avez qu'un seul appel dans votre test, assurez vous + d'utiliser <span class="new_code">expectOnce</span>.<br> + Utiliser <span class="new_code">$mocked->expectAt(0, 'method', 'args);</span> + tout seul ne permettra qu'à la méthode de ne jamais être appelée. + Vérifier les arguements et le comptage total sont pour le moment + indépendants. + Ajouter une attente <span class="new_code">expectCallCount()</span> quand + vous utilisez <span class="new_code">expectAt()</span> (dans le cas sans appel) + est permis. + </p> + <p> + Comme les assertions à l'intérieur des scénarios de test, + toutes ces attentes peuvent incorporer une surchage + sur le message sous la forme d'un paramètre supplémentaire. + Par ailleurs le message original peut être inclus dans la sortie + avec "%s". + </p> + + </div> + References and related information... + <ul> +<li> + Le papier original sur les Objets fantaisie ou + <a href="http://www.mockobjects.com/">Mock objects</a>. + </li> +<li> + La page du projet SimpleTest sur <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page d'accueil de SimpleTest sur <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/overview.html b/3rdparty/simpletest/docs/fr/overview.html new file mode 100644 index 00000000000..968bbc48e50 --- /dev/null +++ b/3rdparty/simpletest/docs/fr/overview.html @@ -0,0 +1,321 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title> + Aperçu et liste des fonctionnalités des testeurs unitaires PHP et web de SimpleTest PHP + </title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Apercu de SimpleTest</h1> + This page... + <ul> +<li> + <a href="#resume">Résumé rapide</a> de l'outil SimpleTest pour PHP. + </li> +<li> + <a href="#fonctionnalites">La liste des fonctionnalites</a>, à la fois présentes et à venir. + </li> +<li> + Il y a beaucoup de <a href="#ressources">ressources sur les tests unitaires</a> sur le web. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="resume"></a>Qu'est-ce que SimpleTest ?</h2> + <p> + Le coeur de SimpleTest est un framework de test construit autour de classes de scénarios de test. Celles-ci sont écrites comme des extensions des classes premières de scénarios de test, chacune élargie avec des méthodes qui contiennent le code de test effectif. Les scripts de test de haut niveau invoque la méthode <span class="new_code">run()</span> à chaque scénario de test successivement. Chaque méthode de test est écrite pour appeler des assertions diverses que le développeur suppose être vraies, <span class="new_code">assertEqual()</span> par exemple. Si l'assertion est correcte, alors un succès est expédié au rapporteur observant le test, mais toute erreur déclenche une alerte et une description de la dissension. + </p> + <p> + Un <a href="unit_test_documentation.html">scénario de test</a> ressemble à... +<pre> +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> + Ces outils sont conçus pour le développeur. Les tests sont écrits en PHP directement, plus ou moins simultanément avec la construction de l'application elle-même. L'avantage d'utiliser PHP lui-même comme langage de test est qu'il n'y a pas de nouveau langage à apprendre, les tests peuvent commencer directement et le développeur peut tester n'importe quelle partie du code. Plus simplement, toutes les parties qui peuvent être accédées par le code de l'application peuvent aussi être accédées par le code de test si ils sont tous les deux dans le même langage. + </p> + <p> + Le type de scénario de test le plus simple est le <span class="new_code">UnitTestCase</span>. Cette classe de scénario de test inclut les tests standards pour l'égalité, les références et l'appariement de motifs (via les expressions rationnelles). Ceux-ci testent ce que vous seriez en droit d'attendre du résultat d'une fonction ou d'une méthode. Il s'agit du type de test le plus commun pendant le quotidien du développeur, peut-être 95% des scénarios de test. + </p> + <p> + La tâche ultime d'une application web n'est cependant pas de produire une sortie correcte à partir de méthodes ou d'objets, mais plutôt de produire des pages web. La classe <span class="new_code">WebTestCase</span> teste des pages web. Elle simule un navigateur web demandant une page, de façon exhaustive : cookies, proxies, connexions sécurisées, authentification, formulaires, cadres et la plupart des éléments de navigation. Avec ce type de scénario de test, le développeur peut garantir que telle ou telle information est présente dans la page et que les formulaires ainsi que les sessions sont gérés comme il faut. + </p> + <p> + Un <a href="web_tester_documentation.html">scénario de test web</a> ressemble à... +<pre> +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> + + <h2> +<a class="target" name="fonctionnalites"></a>Liste des fonctionnalites</h2> + <p> + Ci-dessous vous trouverez un canevas assez brut des fonctionnalités à aujourd'hui et pour demain, sans oublier leur date approximative de publication. J'ai bien peur qu'il soit modifiable sans pré-avis étant donné que les jalons dépendent beaucoup sur le temps disponible. Les trucs en vert ont été codés, mais pas forcément déjà rendus public. Si vous avez une besoin pressant pour une fonctionnalité verte mais pas encore publique alors vous devriez retirer le code directement sur le CVS chez SourceFourge. Une fonctionnalitée publiée est indiqué par "Fini". + <table> +<thead> + <tr> +<th>Fonctionnalité</th> +<th>Description</th> +<th>Publication</th> +</tr> + </thead> +<tbody> +<tr> + <td>Scénariot de test unitaire</td> + <td>Les classes de test et assertions de base</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Affichage HTML</td> + <td>L'affichage le plus simple possible</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Autochargement des scénarios de test</td> + <td>Lire un fichier avec des scénarios de test et les charger dans un groupe de tests automatiquement</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Générateur de code d'objets fantaisie</td> + <td>Des objets capable de simuler d'autres objets, supprimant les dépendances dans les tests</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Bouchons serveur</td> + <td>Des objets fantaisie sans résultat attendu à utiliser à l'extérieur des scénarios de test, pour le prototypage par exemple.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Intégration d'autres testeurs unitaires</td> + <td> + La capacité de lire et simuler d'autres scénarios de test en provenance de PHPUnit et de PEAR::Phpunit.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Scénario de test web</td> + <td>Appariement basique de motifs dans une page téléchargée.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Analyse de page HTML</td> + <td>Permet de suivre les liens et de trouver la balise de titre</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Simulacre partiel</td> + <td>Simuler des parties d'une classe pour tester moins qu'une classe ou dans des cas complexes.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Gestion des cookies Web</td> + <td>Gestion correcte des cookies au téléchargement d'une page.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Suivi des redirections</td> + <td>Le téléchargement d'une page suit automatiquement une redirection 300.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Analyse d'un formulaire</td> + <td>La capacité de valider un formulaire simple et d'en lire les valeurs par défaut.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Interface en ligne de commande</td> + <td>Affiche le résultat des tests sans navigateur web.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Mise à nu des attentes d'une classe</td> + <td>Peut créer des tests précis avec des simulacres ainsi que des scénarios de test.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Sortie et analyse XML</td> + <td>Permet de tester sur plusieurs hôtes et d'intégrer des extensions d'acceptation de test.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Scénario de test en ligne de commande</td> + <td>Permet de tester des outils ou scripts en ligne de commande et de manier des fichiers.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Compatibilité avec PHP Documentor</td> + <td>Génération automatique et complète de la documentation au niveau des classes.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Interface navigateur</td> + <td>Mise à nu des niveaux bas de l'interface du navigateur web pour des scénarios de test plus précis.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Authentification HTTP</td> + <td>Téléchargement des pages web protégées avec une authentification basique seulement.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Boutons de navigation d'un navigateur</td> + <td>Arrière, avant et recommencer</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Support de SSL</td> + <td>Peut se connecter à des pages de type https.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Support de proxy</td> + <td>Peut se connecter via des proxys communs</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Support des cadres</td> + <td>Gère les cadres dans les scénarios de test web.</td> + <td style="color: green;">Fini</td> + </tr> + <tr> + <td>Test de l'upload de fichier</td> + <td>Peut simuler la balise input de type file</td> + <td style="color: red;">1.0.1</td> + </tr> + <tr> + <td>Amélioration sur la machinerie des rapports</td> + <td>Retouche sur la transmission des messages pour une meilleur coopération avec les IDEs</td> + <td style="color: red;">1.1</td> + </tr> + <tr> + <td>Amélioration de l'affichage des tests</td> + <td>Une meilleure interface graphique web, avec un arbre des scénarios de test.</td> + <td style="color: red;">1.1</td> + </tr> + <tr> + <td>Localisation</td> + <td>Abstraction des messages et génration du code à partir de fichiers XML.</td> + <td style="color: red;">1.1</td> + </tr> + <tr> + <td>Simulation d'interface</td> + <td>Peut générer des objets fantaisie tant vers des interfaces que vers des classes.</td> + <td style="color: red;">2.0</td> + </tr> + <tr> + <td>Test sur es exceptions</td> + <td>Dans le même esprit que sur les tests des erreurs PHP.</td> + <td style="color: red;">2.0</td> + </tr> + <tr> + <td>Rercherche d'éléments avec XPath</td> + <td>Peut utiliser Tidy HTML pour un appariement plus rapide et plus souple.</td> + <td style="color: red;">2.0</td> + </tr> + </tbody> +</table> + La migration vers PHP5 commencera juste après la série des 1.0, à partir de là PHP4 ne sera plus supporté. SimpleTest est actuellement compatible avec PHP5 mais n'utilisera aucune des nouvelles fonctionnalités avant la version 2. + </p> + + <h2> +<a class="target" name="ressources"></a>Ressources sur le web pour les tests</h2> + <p> + Le processus est au moins aussi important que les outils. Le type de procédure que fait un usage le plus intensif des outils de test pour développeur est bien sûr l'<a href="http://www.extremeprogramming.org/">Extreme Programming</a>. Il s'agit là d'une des <a href="http://www.agilealliance.com/articles/index">méthodes agiles</a> qui combinent plusieurs pratiques pour "lisser la courbe de coût" du développement logiciel. La plus extrème reste le <a href="http://www.testdriven.com/modules/news/">développement piloté par les tests</a>, où vous devez adhérer à la règle du <cite>pas de code avant d'avoir un test</cite>. Si vous êtes plutôt du genre planninficateur ou que vous estimez que l'expérience compte plus que l'évolution, vous préférerez peut-être l'approche <a href="http://www.therationaledge.com/content/dec_01/f_spiritOfTheRUP_pk.html">RUP</a>. Je ne l'ai pas testé mais je peux voir où vous aurez besoin d'outils de test (cf. illustration 9). + </p> + <p> + La plupart des testeurs unitaires sont dans une certaine mesure un clone de <a href="http://www.junit.org/">JUnit</a>, au moins dans l'interface. Il y a énormément d'information sur le site de JUnit, à commencer par la <a href="http://junit.sourceforge.net/doc/faq/faq.htm">FAQ</a> quie contient pas mal de conseils généraux sur les tests. Une fois mordu par le bogue vous apprécierez sûrement la phrase <a href="http://junit.sourceforge.net/doc/testinfected/testing.htm">infecté par les tests</a> trouvée par Eric Gamma. Si vous êtes encore en train de tergiverser sur un testeur unitaire, sachez que les choix principaux sont <a href="http://phpunit.sourceforge.net/">PHPUnit</a> et <a href="http://pear.php.net/manual/en/package.php.phpunit.php">Pear PHP::PHPUnit</a>. De nombreuses fonctionnalités de SimpleTest leurs font défaut, mais la version PEAR a d'ores et déjà été mise à jour pour PHP5. Elle est aussi recommandée si vous portez des scénarios de test existant depuis <a href="http://www.junit.org/">JUnit</a>. + </p> + <p> + Les développeurs de bibliothèque n'ont pas l'air de livrer très souvent des tests avec leur code : c'est bien dommage. Le code d'une bibliothèque qui inclut des tests peut être remanié avec plus de sécurité et le code de test sert de documentation additionnelle dans un format assez standard. Ceci peut épargner la pêche aux indices dans le code source lorsque qu'un problème survient, en particulier lors de la mise à jour d'une telle bibliothèque. Parmi les bibliothèques utilisant SimpleTest comme testeur unitaire on retrouve <a href="http://wact.sourceforge.net/">WACT</a> et <a href="http://sourceforge.net/projects/htmlsax">PEAR::XML_HTMLSax</a>. + </p> + <p> + Au jour d'aujourd'hui il manque tristement beaucoup de matière sur les objets fantaisie : dommage, surtout que tester unitairement sans eux représente pas mal de travail en plus. L'<a href="http://www.sidewize.com/company/mockobjects.pdf">article original sur les objets fantaisie</a> est très orienté Java, mais reste intéressant à lire. Etant donné qu'il s'agit d'une nouvelle technologie il y a beaucoup de discussions et de débats sur comment les utiliser, souvent sur des wikis comme <a href="http://xpdeveloper.com/cgi-bin/oldwiki.cgi?MockObjects">Extreme Tuesday</a> ou <a href="http://www.mockobjects.com/MocksObjectsPaper.html">www.mockobjects.com</a>ou <a href="http://c2.com/cgi/wiki?MockObject">the original C2 Wiki</a>. Injecter des objets fantaisie dans une classe est un des champs principaux du débat : cet <a href="http://www-106.ibm.com/developerworks/java/library/j-mocktest.html">article chez IBM</a> en est un bon point de départ. + </p> + <p> + Il y a énormement d'outils de test web mais la plupart sont écrits en Java. De plus les tutoriels et autres conseils sont plutôt rares. Votre seul espoir est de regarder directement la documentation pour <a href="http://httpunit.sourceforge.net/">HTTPUnit</a>, <a href="http://htmlunit.sourceforge.net/">HTMLUnit</a> ou <a href="http://jwebunit.sourceforge.net/">JWebUnit</a> et d'espérer y trouver pour des indices. Il y a aussi des frameworks basés sur XML, mais de nouveau la plupart ont besoin de Java pour tourner. + </p> + + </div> + References and related information... + <ul> +<li> + <a href="unit_test_documentation.html">Documentation pour SimpleTest</a>. + </li> +<li> + <a href="http://www.lastcraft.com/first_test_tutorial.php">Comment écrire des scénarios de test en PHP</a> est un tutoriel plutôt avancé. + </li> +<li> + <a href="http://simpletest.org/api/">L'API de SimpleTest</a> par phpdoc. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/partial_mocks_documentation.html b/3rdparty/simpletest/docs/fr/partial_mocks_documentation.html new file mode 100644 index 00000000000..740ae7b4026 --- /dev/null +++ b/3rdparty/simpletest/docs/fr/partial_mocks_documentation.html @@ -0,0 +1,475 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : les objets fantaisie partiels</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur les objets fantaisie partiels</h1> + This page... + <ul> +<li> + <a href="#injection">Le problème de l'injection d'un objet fantaisie</a>. + </li> +<li> + Déplacer la création vers une méthode <a href="#creation">fabrique protégée</a>. + </li> +<li> + <a href="#partiel">L'objet fantaisie partiel</a> génère une sous-classe. + </li> +<li> + Les objets fantaisie partiels <a href="#moins">testent moins qu'une classe</a>. + </li> +</ul> +<div class="content"> + + <p> + Un objet fantaisie partiel n'est ni plus ni moins + qu'un modèle de conception pour soulager un problème spécifique + du test avec des objets fantaisie, celui de placer + des objets fantaisie dans des coins serrés. + Il s'agit d'un outil assez limité et peut-être même + une idée pas si bonne que ça. Elle est incluse dans SimpleTest + pour la simple raison que je l'ai trouvée utile + à plus d'une occasion et qu'elle m'a épargnée + pas mal de travail dans ces moments-là. + </p> + + <h2> +<a class="target" name="injection"></a>Le problème de l'injection dans un objet fantaisie</h2> + <p> + Quand un objet en utilise un autre il est très simple + d'y faire circuler une version fantaisie déjà prête + avec ses attentes. Les choses deviennent un peu plus délicates + si un objet en crée un autre et que le créateur est celui + que l'on souhaite tester. Cela revient à dire que l'objet + créé devrait être une fantaisie, mais nous pouvons + difficilement dire à notre classe sous test de créer + un objet fantaisie plutôt qu'un "vrai" objet. + La classe testée ne sait même pas qu'elle travaille dans un environnement de test. + </p> + <p> + Par exemple, supposons que nous sommes en train + de construire un client telnet et qu'il a besoin + de créer une socket réseau pour envoyer ses messages. + La méthode de connexion pourrait ressemble à quelque chose comme... +<pre> +<strong><?php +require_once('socket.php'); + +class Telnet { + ... + function connect($ip, $port, $username, $password) { + $socket = new Socket($ip, $port); + $socket->read( ... ); + ... + } +} +?></strong> +</pre> + Nous voudrions vraiment avoir une version fantaisie + de l'objet socket, que pouvons nous faire ? + </p> + <p> + La première solution est de passer la socket en + tant que paramètre, ce qui force la création + au niveau inférieur. Charger le client de cette tâche + est effectivement une bonne approche si c'est possible + et devrait conduire à un remaniement -- de la création + à partir de l'action. En fait, c'est là une des manières + avec lesquels tester en s'appuyant sur des objets fantaisie + vous force à coder des solutions plus resserrées sur leur objectif. + Ils améliorent votre programmation. + </p> + <p> + Voici ce que ça devrait être... +<pre> +<?php +require_once('socket.php'); + +class Telnet { + ... + <strong>function connect($socket, $username, $password) { + $socket->read( ... ); + ... + }</strong> +} +?> +</pre> + Sous-entendu, votre code de test est typique d'un cas + de test avec un objet fantaisie. +<pre> +class TelnetTest extends UnitTestCase { + ... + function testConnection() {<strong> + $socket = new MockSocket(); + ... + $telnet = new Telnet(); + $telnet->connect($socket, 'Me', 'Secret'); + ...</strong> + } +} +</pre> + C'est assez évident que vous ne pouvez descendre que d'un niveau. + Vous ne voudriez pas que votre application de haut niveau + crée tous les fichiers de bas niveau, sockets et autres connexions + à la base de données dont elle aurait besoin. + Elle ne connaîtrait pas les paramètres du constructeur de toute façon. + </p> + <p> + La solution suivante est de passer l'objet créé sous la forme + d'un paramètre optionnel... +<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> + Pour une solution rapide, c'est généralement suffisant. + Ensuite le test est très similaire : comme si le paramètre + était transmis formellement... +<pre> +class TelnetTest extends UnitTestCase { + ... + function testConnection() {<strong> + $socket = new MockSocket(); + ... + $telnet = new Telnet(); + $telnet->connect('127.0.0.1', 21, 'Me', 'Secret', $socket); + ...</strong> + } +} +</pre> + Le problème de cette approche tient dans son manque de netteté. + Il y a du code de test dans la classe principale et aussi + des paramètres transmis dans le scénario de test + qui ne sont jamais utilisés. Il s'agit là d'une approche + rapide et sale, mais qui ne reste pas moins efficace + dans la plupart des situations. + </p> + <p> + Une autre solution encore est de laisser un objet fabrique + s'occuper de la création... +<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> + Il s'agit là probablement de la réponse la plus travaillée + étant donné que la création est maintenant située + dans une petite classe spécialisée. La fabrique réseau + peut être testée séparément et utilisée en tant que fantaisie + quand nous testons la classe telnet... +<pre> +class TelnetTest extends UnitTestCase { + ... + function testConnection() {<strong> + $socket = new MockSocket(); + ... + $network = new MockNetwork(); + $network->returnsByReference('createSocket', $socket); + $telnet = new Telnet($network); + $telnet->connect('127.0.0.1', 21, 'Me', 'Secret');</strong> + } +} +</pre> + Le problème reste que nous ajoutons beaucoup de classes + à la bibliothèque. Et aussi que nous utilisons beaucoup + de fabriques ce qui rend notre code un peu moins intuitif. + La solution la plus flexible, mais aussi la plus complexe. + </p> + <p> + Des techniques comme "l'Injection de Dépendance" + (ou "Dependency Injection") s'attelle au problème + de l'instanciation d'une classe avec beaucoup de paramètres. + Malheureusement la connaissance de ce patron de conception + n'est pas très répandue et si vous êtes en train d'essayer + de faire fonctionner du vieux code, ré-achitecturer toute + l'application n'est pas vraiment une option. + </p> + <p> + Peut-on trouver un juste milieu ? + </p> + + <h2> +<a class="target" name="creation"></a>Méthode fabrique protégée</h2> + <p> + Il existe une technique pour palier à ce problème + sans créer de nouvelle classe dans l'application; + par contre elle induit la création d'une sous-classe au moment du test. + Premièrement nous déplaçons la création de la socket dans sa propre méthode... +<pre> +<?php +require_once('socket.php'); + +class Telnet { + ... + function connect($ip, $port, $username, $password) { + <strong>$socket = $this->createSocket($ip, $port);</strong> + $socket->read( ... ); + ... + }<strong> + + protected function createSocket($ip, $port) { + return new Socket($ip, $port); + }</strong> +} +?> +</pre> + Une première étape plutôt précautionneuse même pour + du code legacy et intermélé. + Il s'agit là de la seule modification dans le code de l'application. + </p> + <p> + Pour le scénario de test, nous devons créer + une sous-classe de manière à intercepter la création de la socket... +<pre> +<strong>class TelnetTestVersion extends Telnet { + var $mock; + + function TelnetTestVersion($mock) { + $this->mock = $mock; + $this->Telnet(); + } + + protected function createSocket() { + return $this->mock; + } +}</strong> +</pre> + Ici j'ai déplacé la fantaisie dans le constructeur, + mais un setter aurait fonctionné tout aussi bien. + Notez bien que la fantaisie est placée dans une variable + d'objet avant que le constructeur ne soit attaché. + C'est nécessaire dans le cas où le constructeur appelle + <span class="new_code">connect()</span>. + Autrement il pourrait donner un valeur nulle à partir de + <span class="new_code">createSocket()</span>. + </p> + <p> + Après la réalisation de tout ce travail supplémentaire + le scénario de test est assez simple. + Nous avons juste besoin de tester notre nouvelle classe à la place... +<pre> +class TelnetTest extends UnitTestCase { + ... + function testConnection() {<strong> + $socket = new MockSocket(); + ... + $telnet = new TelnetTestVersion($socket); + $telnet->connect('127.0.0.1', 21, 'Me', 'Secret');</strong> + } +} +</pre> + Cette nouvelle classe est très simple bien sûr. + Elle ne fait qu'initier une valeur renvoyée, à la manière + d'une fantaisie. Ce serait pas mal non plus si elle pouvait + vérifier les paramètres entrants. + Exactement comme un objet fantaisie. + Il se pourrait bien que nous ayons à réaliser cette astuce régulièrement : + serait-il possible d'automatiser la création de cette sous-classe ? + </p> + + <h2> +<a class="target" name="partiel"></a>Un objet fantaisie partiel</h2> + <p> + Bien sûr la réponse est "oui" + ou alors j'aurais arrêté d'écrire depuis quelques temps déjà ! + Le test précédent a représenté beaucoup de travail, + mais nous pouvons générer la sous-classe en utilisant + une approche à celle des objets fantaisie. + </p> + <p> + Voici donc une version avec objet fantaisie partiel du test... +<pre> +<strong>Mock::generatePartial( + 'Telnet', + 'TelnetTestVersion', + array('createSocket'));</strong> + +class TelnetTest extends UnitTestCase { + ... + function testConnection() {<strong> + $socket = new MockSocket(); + ... + $telnet = new TelnetTestVersion(); + $telnet->setReturnReference('createSocket', $socket); + $telnet->Telnet(); + $telnet->connect('127.0.0.1', 21, 'Me', 'Secret');</strong> + } +} +</pre> + La fantaisie partielle est une sous-classe de l'original + dont on aurait "remplacé" les méthodes sélectionnées + avec des versions de test. L'appel à <span class="new_code">generatePartial()</span> + nécessite trois paramètres : la classe à sous classer, + le nom de la nouvelle classe et une liste des méthodes à simuler. + </p> + <p> + Instancier les objets qui en résultent est plutôt délicat. + L'unique paramètre du constructeur d'un objet fantaisie partiel + est la référence du testeur unitaire. + Comme avec les objets fantaisie classiques c'est nécessaire + pour l'envoi des résultats de test en réponse à la vérification des attentes. + </p> + <p> + Une nouvelle fois le constructeur original n'est pas lancé. + Indispensable dans le cas où le constructeur aurait besoin + des méthodes fantaisie : elles n'ont pas encore été initiées ! + Nous initions les valeurs retournées à cet instant et + ensuite lançons le constructeur avec ses paramètres normaux. + Cette construction en trois étapes de "new", + suivie par la mise en place des méthodes et ensuite + par la lancement du constructeur proprement dit est + ce qui distingue le code d'un objet fantaisie partiel. + </p> + <p> + A part pour leur construction, toutes ces méthodes + fantaisie ont les mêmes fonctionnalités que dans + le cas des objets fantaisie et toutes les méthodes + non fantaisie se comportent comme avant. + Nous pouvons mettre en place des attentes très facilement... +<pre> +class TelnetTest extends UnitTestCase { + ... + function testConnection() { + $socket = new MockSocket(); + ... + $telnet = new TelnetTestVersion(); + $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'); + } +} +</pre> + Les objets fantaisie partiels ne sont pas très utilisés. + Je les considère comme transitoire. + Utile lors d'un remaniement, mais une fois que l'application + a eu toutes ses dépendances bien séparées alors + ils peuvent disparaître. + </p> + + <h2> +<a class="target" name="moins"></a>Tester moins qu'une classe</h2> + <p> + Les méthodes issues d'un objet fantaisie n'ont pas + besoin d'être des méthodes fabrique, Il peut s'agir + de n'importe quelle sorte de méthode. + Ainsi les objets fantaisie partiels nous permettent + de prendre le contrôle de n'importe quelle partie d'une classe, + le constructeur excepté. Nous pourrions même aller jusqu'à + créer des fantaisies sur toutes les méthodes à part celle + que nous voulons effectivement tester. + </p> + <p> + Cette situation est assez hypothétique, étant donné + que je ne l'ai pas souvent essayée. + Je crains qu'en forçant la granularité d'un objet + on n'obtienne pas forcément un code de meilleur qualité. + Personnellement j'utilise les objets fantaisie partiels + comme moyen de passer outre la création ou alors + de temps en temps pour tester le modèle de conception TemplateMethod. + </p> + <p> + On en revient toujours aux standards de code de votre projet : + c'est à vous de trancher si vous autorisez ce mécanisme ou non. + </p> + + </div> + References and related information... + <ul> +<li> + La page du projet SimpleTest sur + <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + <a href="http://simpletest.org/api/">L'API complète pour SimpleTest</a> + à partir de PHPDoc. + </li> +<li> + La méthode fabrique protégée est décrite dans + <a href="http://www-106.ibm.com/developerworks/java/library/j-mocktest.html"> + cet article d'IBM</a>. Il s'agit de l'unique papier + formel que j'ai vu sur ce problème. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/reporter_documentation.html b/3rdparty/simpletest/docs/fr/reporter_documentation.html new file mode 100644 index 00000000000..485fc74c7a4 --- /dev/null +++ b/3rdparty/simpletest/docs/fr/reporter_documentation.html @@ -0,0 +1,630 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : le rapporteur de test</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur le rapporteur de test</h1> + This page... + <ul> +<li> + Afficher <a href="#html">les résultats en HTML</a> + </li> +<li> + Afficher et <a href="#autres">rapporter les résultats</a> + dans d'autres formats + </li> +<li> + Utilisé <a href="#cli">SimpleTest depuis la ligne de commande</a> + </li> +<li> + <a href="#xml">Utiliser XML</a> pour des tests distants + </li> +</ul> +<div class="content"> + + <p> + SimpleTest suit plutôt plus que moins le modèle MVC (Modèle-Vue-Contrôleur). + Les classes "reporter" sont les vues et les modèles + sont vos scénarios de test et leur hiérarchie. + Le contrôleur est le plus souvent masqué à l'utilisateur + de SimpleTest à moins de vouloir changer la façon + dont les tests sont effectivement exécutés, + auquel cas il est possible de surcharger les objets + "runner" (ceux de l'exécuteur) depuis l'intérieur + d'un scénario de test. Comme d'habitude avec MVC, + le contrôleur est plutôt indéfini et il existe d'autres endroits + pour contrôler l'exécution des tests. + </p> + + <h2> +<a class="target" name="html"></a>Les résultats rapportés au format HTML</h2> + <p> + L'affichage par défaut est minimal à l'extrême. + Il renvoie le succès ou l'échec avec les barres conventionnelles + - rouge et verte - et affichent une trace d'arborescence + des groupes de test pour chaque assertion erronée. Voici un tel échec... + <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> + Alors qu'ici tous les tests passent... + <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> + La bonne nouvelle, c'est qu'il existe pas mal de points + dans la hiérarchie de l'affichage pour créer des sous-classes. + </p> + <p> + Pour l'affichage basé sur des pages web, + il y a la classe <span class="new_code">HtmlReporter</span> avec la signature suivante... +<pre> +class HtmlReporter extends SimpleReporter { + public __construct($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> + Voici ce que certaines de ces méthodes veulent dire. + Premièrement les méthodes d'affichage que vous voudrez probablement surcharger... + <ul class="api"> + <li> + <span class="new_code">HtmlReporter(string $encoding)</span><br> + est le constructeur. Notez que le test unitaire initie + le lien à l'affichage plutôt que l'opposé. + L'affichage est principalement un receveur passif + des évènements de tests. Cela permet d'adapter + facilement l'affichage pour d'autres systèmes + en dehors des tests unitaires, tel le suivi + de la charge de serveurs. + L'"encoding" est le type d'encodage + que vous souhaitez utiliser pour l'affichage du test. + Pour pouvoir effectuer un rendu correct de la sortie + de débogage quand on utilise le testeur web, + il doit correspondre à l'encodage du site testé. + Les chaînes de caractères disponibles + sont indiquées dans la fonction PHP + <a href="http://www.php.net/manual/fr/function.htmlentities.php">html_entities()</a>. + </li> + <li> + <span class="new_code">void paintHeader(string $test_name)</span><br> + est appelé une fois, au début du test quand l'évènement + de démarrage survient. Le premier évènement de démarrage + est souvent délivré par le groupe de tests du niveau + le plus haut et donc c'est de là que le + <span class="new_code">$test_name</span> arrive. + Il peint le titre de la page, CSS, la balise "body", etc. + Il ne renvoie rien du tout (<span class="new_code">void</span>). + </li> + <li> + <span class="new_code">void paintFooter(string $test_name)</span><br> + est appelé à la toute fin du test pour fermer + les balises ouvertes par l'entête de la page. + Par défaut il affiche aussi la barre rouge ou verte + et le décompte final des résultats. + En fait la fin des tests arrive quand l'évènement + de fin de test arrive avec le même nom + que celui qui l'a initié au même niveau. + Le nid des tests en quelque sorte. + Fermer le dernier test finit l'affichage. + </li> + <li> + <span class="new_code">void paintMethodStart(string $test_name)</span><br> + est appelé au début de chaque méthode de test. + Normalement le nom vient de celui de la méthode. + Les autres évènements de départ de test + se comportent de la même manière sauf que + celui du groupe de tests indique au rapporteur + le nombre de scénarios de test qu'il contient. + De la sorte le rapporteur peut afficher une barre + de progrès au fur et à mesure que l'exécuteur + passe en revue les scénarios de test. + </li> + <li> + <span class="new_code">void paintMethodEnd(string $test_name)</span><br> + clôt le test lancé avec le même nom. + </li> + <li> + <span class="new_code">void paintFail(string $message)</span><br> + peint un échec. Par défaut il ne fait qu'afficher + le mot "fail", une trace d'arborescence + affichant la position du test en cours + et le message transmis par l'assertion. + </li> + <li> + <span class="new_code">void paintPass(string $message)</span><br> + ne fait rien, par défaut. + </li> + <li> + <span class="new_code">string getCss()</span><br> + renvoie les styles CSS sous la forme d'une chaîne + à l'attention de la méthode d'entêtes d'une page. + Des styles additionnels peuvent être ajoutés ici + si vous ne surchargez pas les entêtes de la page. + Vous ne voudrez pas utiliser cette méthode dans + des entêtes d'une page surchargée si vous souhaitez + inclure le feuille de style CSS d'origine. + </li> + </ul> + Il y a aussi des accesseurs pour aller chercher l'information + sur l'état courant de la suite de test. Vous les utiliserez + pour enrichir l'affichage... + <ul class="api"> + <li> + <span class="new_code">array getTestList()</span><br> + est la première méthode très commode pour les sous-classes. + Elle liste l'arborescence courante des tests + sous la forme d'une liste de noms de tests. + Le premier test -- celui de premier niveau -- + sera le premier dans la liste et la méthode de test + en cours sera la dernière. + </li> + <li> + <span class="new_code">integer getPassCount()</span><br> + renvoie le nombre de succès atteint. Il est nécessaire + pour l'affichage à la fin. + </li> + <li> + <span class="new_code">integer getFailCount()</span><br> + renvoie de la même manière le nombre d'échecs. + </li> + <li> + <span class="new_code">integer getExceptionCount()</span><br> + renvoie quant à lui le nombre d'erreurs. + </li> + <li> + <span class="new_code">integer getTestCaseCount()</span><br> + est le nombre total de scénarios lors de l'exécution des tests. + Il comprend aussi les tests groupés. + </li> + <li> + <span class="new_code">integer getTestCaseProgress()</span><br> + est le nombre de scénarios réalisés jusqu'à présent. + </li> + </ul> + Une modification simple : demander à l'HtmlReporter d'afficher + aussi bien les succès que les échecs et les erreurs... +<pre> +<strong>class ReporterShowingPasses 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"; + } + + protected function getCss() { + return parent::getCss() . ' .pass { color: green; }'; + } +}</strong> +</pre> + </p> + <p> + Une méthode qui a beaucoup fait jaser reste la méthode <span class="new_code">makeDry()</span>. + Si vous lancez cette méthode, sans paramètre, + sur le rapporteur avant que la suite de test + ne soit exécutée alors aucune méthode de test + ne sera appelée. Vous continuerez à avoir + les évènements entrants et sortants des méthodes + et scénarios de test, mais aucun succès ni échec ou erreur, + parce que le code de test ne sera pas exécuté. + </p> + <p> + La raison ? Pour permettre un affichage complexe + d'une IHM (ou GUI) qui permettrait la sélection + de scénarios de test individuels. + Afin de construire une liste de tests possibles, + ils ont besoin d'un rapport sur la structure du test + pour l'affichage, par exemple, d'une vue en arbre + de la suite de test. Avec un rapporteur lancé + sur une exécution sèche qui ne renverrait + que les évènements d'affichage, cela devient + facilement réalisable. + </p> + + <h2> +<a class="target" name="autre"></a>Etendre le rapporteur</h2> + <p> + Plutôt que de modifier l'affichage existant, + vous voudrez peut-être produire une présentation HTML + complètement différente, ou même générer une version texte ou XML. + Plutôt que de surcharger chaque méthode dans + <span class="new_code">HtmlReporter</span> nous pouvons nous rendre + une étape plus haut dans la hiérarchie de classe vers + <span class="new_code">SimpleReporter</span> dans le fichier source <em>simple_test.php</em>. + </p> + <p> + Un affichage sans rien, un canevas vierge + pour votre propre création, serait... +<pre> +<strong>require_once('simpletest/simpletest.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> + } + + function paintError($message) {<strong> + parent::paintError($message);</strong> + } + + function paintException($exception) {<strong> + parent::paintException($exception);</strong> + } +} +</pre> + Aucune sortie ne viendrait de cette classe jusqu'à un ajout de votre part. + </p> + <p> + Sauf qu'il y a un problème : en utilisant cette cette classe + de bas niveau, vous devez explicitement l'invoquer + dans les scripts de test. + La commande "autorun" ne sera pas capable + d'utiliser son contexte courant (qu'elle soit lancée + dans un navigateur web ou via une ligne de commande) + pour sélectionner le rapporteur. + </p> + <p> + Vous invoquez explicitement la lanceur de tests comme suit... +<pre> +<?php +require_once('simpletest/autorun.php'); + +$test = new TestSuite('File test'); +$test->addFile('tests/file_test.php'); +$test->run(<strong>new MyReporter()</strong>); +?> +</pre> + ...ou peut-être comme cela... +<pre> +<?php +require_once('simpletest/simpletest.php'); +require_once('my_reporter.php'); + +class MyTest extends TestSuite { + function __construct() { + parent::__construct(); + $this->addFile('tests/file_test.php'); + } +} + +$test = new MyTest(); +$test->run(<strong>new MyReporter()</strong>); +?> +</pre> + Nous verrons plus comment l'intégrer avec l'"autorun". + </p> + + <h2> +<a class="target" name="cli"></a>Le rapporteur en ligne de commande</h2> + <p> + SimpleTest est aussi livré avec un rapporteur + en ligne de commande, minime lui aussi. + Pour utiliser le rapporteur en ligne de commande explicitement, + il suffit de l'intervertir avec celui de la version HTML... +<pre> +<?php +require_once('simpletest/autorun.php'); + +$test = new TestSuite('File test'); +$test->addFile('tests/file_test.php'); +$test->run(<strong>new TextReporter()</strong>); +?> +</pre> + Et ensuite d'invoquer la suite de test à partir d'une ligne de commande... +<pre class="shell"> +php file_test.php +</pre> + Bien sûr vous aurez besoin d'installer PHP + en ligne de commande. Une suite de test qui + passerait toutes ses assertions ressemble à... +<pre class="shell"> +File test +OK +Test cases run: 1/1, Passes: 1, Failures: 0, Exceptions: 0 +</pre> + Un échec déclenche un affichage comme... +<pre class="shell"> +File test +1) True assertion failed. + in createNewFile +FAILURES!!! +Test cases run: 1/1, Passes: 0, Failures: 1, Exceptions: 0 +</pre> + </p> + <p> + Une des principales raisons pour utiliser + une suite de test en ligne de commande tient + dans l'utilisation possible du testeur avec + un processus automatisé. Pour fonctionner comme + il faut dans des scripts shell le script de test + devrait renvoyer un code de sortie non-nul suite à un échec. + Si une suite de test échoue la valeur <span class="new_code">false</span> + est renvoyée par la méthode <span class="new_code">SimpleTest::run()</span>. + Nous pouvons utiliser ce résultat pour terminer le script + avec la bonne valeur renvoyée... +<pre> +<?php +require_once('simpletest/autorun.php'); + +$test = new TestSuite('File test'); +$test->addFile('tests/file_test.php'); +<strong>exit ($test->run(new TextReporter()) ? 0 : 1);</strong> +?> +</pre> + Bien sûr l'objectif ne serait pas de créer deux scripts de test, + l'un en ligne de commande et l'autre pour un navigateur web, + pour chaque suite de test. + Le rapporteur en ligne de commande inclut + une méthode pour déterminer l'environnement d'exécution... +<pre> +<?php +require_once('simpletest/autorun.php'); + +$test = new TestSuite('File test'); +$test->addFile('tests/file_test.php'); +<strong>if (TextReporter::inCli()) {</strong> + exit ($test->run(new TextReporter()) ? 0 : 1); +<strong>}</strong> +$test->run(new HtmlReporter()); +?> +</pre> + Il s'agit là de la forme utilisée par SimpleTest lui-même. + Quand vous utilisez l'"autorun.php" + et qu'aucun test n'a été lancé avant la fin, + c'est quasiment le code que SimpleTest lancera + pour vous implicitement. + </p> + <p> + En d'autres termes, ceci donne le même résultat... +<pre> +<?php +require_once('simpletest/autorun.php'); + +class MyTest extends TestSuite { + function __construct() { + parent::__construct(); + $this->addFile('tests/file_test.php'); + } +} +?> +</pre> </p> + + <h2> +<a class="target" name="xml"></a>Test distant</h2> + <p> + SimpleTest est livré avec une classe <span class="new_code">XmlReporter</span> + utilisée pour de la communication interne. + Lors de son exécution, le résultat ressemble à... +<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> + Pour faire en sorte ue vos scénarios de test produisent ce format, + dans la ligne de commande, ajoutez le flag <span class="new_code">--xml</span>. +<pre class="shell"> +php my_test.php --xml +</pre> + Vous pouvez faire la même chose dans le navigation web + en ajoutant le paramètre <span class="new_code">xml=1</span> dans l'URL. + N'importe quelle valeur "true" fera l'affaire. + </p> + <p> + Vous pouvez utiliser ce format avec le parseur + fourni dans SimpleTest lui-même. + Il s'agit de <span class="new_code">SimpleTestXmlParser</span> + et se trouve <em>xml.php</em> à l'intérieur du paquet SimpleTest... +<pre> +<?php +require_once('simpletest/xml.php'); + +... +$parser = new SimpleTestXmlParser(new HtmlReporter()); +$parser->parse($test_output); +?> +</pre> + <span class="new_code">$test_output</span> devrait être au format XML, + à partir du rapporteur XML, et pourrait venir + d'une exécution en ligne de commande d'un scénario de test. + Le parseur envoie des évènements au rapporteur exactement + comme tout autre exécution de test. + Il y a des occasions bizarres dans lesquelles c'est en fait très utile. + </p> + <p> + Le plus courant, c'est quand vous voulez isoler + un test sensible au crash. + Vous pouvez collecter la sortie XML en utilisant + l'opérateur antiquote (Ndt : backtick) à partir + d'un autre test. + De la sorte, il tourne dans son propre processus... +<pre> +<?php +require_once('simpletest/xml.php'); + +if (TextReporter::inCli()) { + $parser = new SimpleTestXmlParser(new TextReporter()); +} else { + $parser = new SimpleTestXmlParser(new HtmlReporter()); +} +$parser->parse(`php flakey_test.php --xml`); +?> +</pre> + </p> + <p> + Un autre cas est celui des très longues suites de tests. + </p> + <p> + Elles peuvent venir à bout de la limite de mémoire + par défaut d'un process PHP - 16Mb. + En plaçant la sortie des groupes de test dans du XML + et leur exécution dans des process différents, + le résultat peut être parsé à nouveau pour agréger + les résultats avec moins d'impact sur le test au premier niveau. + </p> + <p> + Parce que la sortie XML peut venir de n'importe où, + ça ouvre des possibilités d'agrégation d'exécutions de test + depuis des serveur distants. + Un scénario de test pour le réaliser existe déjà + à l'intérieur du framework SimpleTest, mais il est encore expérimental... +<pre> +<?php +<strong>require_once('../remote.php');</strong> +require_once('simpletest/autorun.php'); + +$test_url = ...; +$dry_url = ...; + +class MyTestOnAnotherServer extends RemoteTestCase { + function __construct() { + $test_url = ... + parent::__construct($test_url, $test_url . ' --dry'); + } +} +?> +</pre> + <span class="new_code">RemoteTestCase</span> prend la localisation réelle + du lanceur de test, tout simplement un page web au format XML. + Il prend aussi l'URL d'un rapporteur initié + pour effectuer une exécution sèche. + Cette technique est employée pour que les progrès + soient correctement rapportés vers le haut. + <span class="new_code">RemoteTestCase</span> peut être ajouté à + une suite de test comme n'importe quelle autre suite de tests. + </p> + + </div> + References and related information... + <ul> +<li> + La page du projet SimpleTest sur + <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page de téléchargement de SimpleTest sur + <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + L'<a href="http://simpletest.org/api/">API pour développeur de SimpleTest</a> + donne tous les détails sur les classes et les assertions disponibles. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/unit_test_documentation.html b/3rdparty/simpletest/docs/fr/unit_test_documentation.html new file mode 100644 index 00000000000..a7c31f95dbb --- /dev/null +++ b/3rdparty/simpletest/docs/fr/unit_test_documentation.html @@ -0,0 +1,447 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest pour les tests de régression en PHP</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur les tests unitaires en PHP</h1> + This page... + <ul> +<li> + <a href="#unitaire">Scénarios de test unitaire</a> + et opérations basiques. + </li> +<li> + <a href="#extension_unitaire">Étendre des scénarios de test</a> + pour les personnaliser à votre propre projet. + </li> +<li> + <a href="#lancement_unitaire">Lancer un scénario seul</a> + comme un script unique. + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="unitaire"></a>Scénarios de tests unitaires</h2> + <p> + Le coeur du système est un framework de tests de régression + construit autour des scénarios de test. + Un exemple de scénario de test ressemble à... +<pre> +<strong>class FileTestCase extends UnitTestCase { +}</strong> +</pre> + Si aucun nom de test n'est fourni au moment + de la liaison avec le constructeur alors + le nom de la classe sera utilisé. + Il s'agit du nom qui sera affiché dans les résultats du test. + </p> + <p> + Les véritables tests sont ajoutés en tant que méthode + dans le scénario de test dont le nom par défaut + commence par la chaîne "test" + et quand le scénario de test est appelé toutes les méthodes + de ce type sont exécutées dans l'ordre utilisé + par l'introspection de PHP pour les trouver. + Peuvent être ajoutées autant de méthodes de test que nécessaires. + Par exemple... +<pre> +require_once('simpletest/autorun.php'); +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> + Le constructeur est optionnel et souvent omis. Sans nom, + le nom de la classe est utilisé comme nom pour le scénario de test. + </p> + <p> + Notre unique méthode de test pour le moment est + <span class="new_code">testCreation()</span> où nous vérifions + qu'un fichier a bien été créé par notre objet + <span class="new_code">Writer</span>. Nous pourrions avoir mis + le code <span class="new_code">unlink()</span> dans cette méthode, + mais en la plaçant dans <span class="new_code">setUp()</span> + et <span class="new_code">tearDown()</span> nous pouvons l'utiliser + pour nos autres méthodes de test que nous ajouterons. + </p> + <p> + La méthode <span class="new_code">setUp()</span> est lancé + juste avant chaque méthode de test. + <span class="new_code">tearDown()</span> est lancé après chaque méthode de test. + </p> + <p> + Vous pouvez placer une initialisation de + scénario de test dans le constructeur afin qu'elle soit lancée + pour toutes les méthodes dans le scénario de test + mais dans un tel cas vous vous exposeriez à des interférences. + Cette façon de faire est légèrement moins rapide, + mais elle est plus sûre. + Notez que si vous arrivez avec des notions de JUnit, + il ne s'agit pas du comportement auquel vous êtes habitués. + Bizarrement JUnit re-instancie le scénario de test + pour chaque méthode de test pour se prévenir + d'une telle interférence. + SimpleTest demande à l'utilisateur final d'utiliser + <span class="new_code">setUp()</span>, mais fournit aux codeurs de bibliothèque d'autres crochets. + </p> + <p> + Pour rapporter les résultats de test, + le passage par une classe d'affichage - notifiée par + les différentes méthodes de type <span class="new_code">assert...()</span> - + est utilisée. En voici la liste complète pour + la classe <span class="new_code">UnitTestCase</span>, + celle par défaut dans SimpleTest... + <table><tbody> + <tr> +<td><span class="new_code">assertTrue($x)</span></td> +<td>Echoue si $x est faux</td> +</tr> + <tr> +<td><span class="new_code">assertFalse($x)</span></td> +<td>Echoue si $x est vrai</td> +</tr> + <tr> +<td><span class="new_code">assertNull($x)</span></td> +<td>Echoue si $x est initialisé</td> +</tr> + <tr> +<td><span class="new_code">assertNotNull($x)</span></td> +<td>Echoue si $x n'est pas initialisé</td> +</tr> + <tr> +<td><span class="new_code">assertIsA($x, $t)</span></td> +<td>Echoue si $x n'est pas de la classe ou du type $t</td> +</tr> + <tr> +<td><span class="new_code">assertEqual($x, $y)</span></td> +<td>Echoue si $x == $y est faux</td> +</tr> + <tr> +<td><span class="new_code">assertNotEqual($x, $y)</span></td> +<td>Echoue si $x == $y est vrai</td> +</tr> + <tr> +<td><span class="new_code">assertIdentical($x, $y)</span></td> +<td>Echoue si $x === $y est faux</td> +</tr> + <tr> +<td><span class="new_code">assertNotIdentical($x, $y)</span></td> +<td>Echoue si $x === $y est vrai</td> +</tr> + <tr> +<td><span class="new_code">assertReference($x, $y)</span></td> +<td>Echoue sauf si $x et $y sont la même variable</td> +</tr> + <tr> +<td><span class="new_code">assertCopy($x, $y)</span></td> +<td>Echoue si $x et $y sont la même variable</td> +</tr> + <tr> +<td><span class="new_code">assertPattern($p, $x)</span></td> +<td>Echoue sauf si l'expression rationnelle $p capture $x</td> +</tr> + <tr> +<td><span class="new_code">assertNoPattern($p, $x)</span></td> +<td>Echoue si l'expression rationnelle $p capture $x</td> +</tr> + <tr> +<td><span class="new_code">expectError($x)</span></td> +<td>Echoue si l'erreur correspondante n'arrive pas</td> +</tr> + <tr> +<td><span class="new_code">expectException($x)</span></td> +<td>Echoue si l'exception correspondante n'est pas levée</td> +</tr> + <tr> +<td><span class="new_code">ignoreException($x)</span></td> +<td>Avale toutes les exceptions correspondantes qui surviendraient</td> +</tr> + <tr> +<td><span class="new_code">assert($e)</span></td> +<td>Echoue sur un objet <a href="expectation_documentation.html">attente</a> $e qui échouerait</td> +</tr> + </tbody></table> + Toutes les méthodes d'assertion peuvent recevoir + une description optionnelle : + cette description sert pour étiqueter le résultat. + Sans elle, une message par défaut est envoyée à la place : + il est généralement suffisant. + Ce message par défaut peut encore être encadré + dans votre propre message si vous incluez "%s" + dans la chaîne. + Toutes les assertions renvoient vrai / true en cas de succès + et faux / false en cas d'échec. + </p> + <p> + D'autres exemples... +<pre> +<strong>$variable = null; +$this->assertNull($variable, 'Should be cleared');</strong> +</pre> + ...passera et normalement n'affichera aucun message. + Si vous avez <a href="http://www.lastcraft.com/display_subclass_tutorial.php"> + configuré le testeur pour afficher aussi les succès</a> + alors le message sera affiché comme tel. +<pre> +<strong>$this->assertIdentical(0, false, 'Zero is not false [%s]');</strong> +</pre> + Ceci échouera étant donné qu'il effectue une vérification + sur le type en plus d'une comparaison sur les deux valeurs. + La partie "%s" est remplacée par le message d'erreur + par défaut qui aurait été affiché si nous n'avions pas fourni le nôtre. + Cela nous permet d'emboîter les messages de test. +<pre> +<strong>$a = 1; +$b = $a; +$this->assertReference($a, $b);</strong> +</pre> + Échouera étant donné que la variable <span class="new_code">$b</span> + est une copie de <span class="new_code">$a</span>. +<pre> +<strong>$this->assertPattern('/hello/i', 'Hello world');</strong> +</pre> + Là, ça passe puisque la recherche est insensible + à la casse et que donc <span class="new_code">hello</span> + est bien repérable dans <span class="new_code">Hello world</span>. +<pre> +<strong>$this->expectError();</strong> +trigger_error('Catastrophe'); +</pre> + Ici la vérification attrape le message "Catastrophe" + sans vérifier le texte et passe. + Elle enlève l'erreur de la queue au passage. +<pre> +<strong>$this->expectError('Catastrophe');</strong> +trigger_error('Catastrophe'); +</pre> + La vérification d'erreur suivante teste non seulement + l'existance de l'erreur mais aussi le texte qui, + dans le cas présent, correspond et donc un nouveau succès. + Si des erreurs non vérifiées sont laissées pour compte + à la fin d'une méthode de test alors un exception sera levé + dans le test. + </p> + <p> + Notez que SimpleTest ne peut pas attraper des erreurs PHP + au moment de la compilation. + </p> + <p> + Les scénarios de tests peuvent utiliser des méthodes + bien pratiques pour déboguer le code ou pour étendre la suite... + <table><tbody> + <tr> +<td><span class="new_code">setUp()</span></td> +<td>Est lancée avant chaque méthode de test</td> +</tr> + <tr> +<td><span class="new_code">tearDown()</span></td> +<td>Est lancée après chaque méthode de test</td> +</tr> + <tr> +<td><span class="new_code">pass()</span></td> +<td>Envoie un succès</td> +</tr> + <tr> +<td><span class="new_code">fail()</span></td> +<td>Envoie un échec</td> +</tr> + <tr> +<td><span class="new_code">error()</span></td> +<td>Envoi un évènement exception</td> +</tr> + <tr> +<td><span class="new_code">signal($type, $payload)</span></td> +<td>Envoie un message défini par l'utilisateur au rapporteur du test</td> +</tr> + <tr> +<td><span class="new_code">dump($var)</span></td> +<td>Effectue un <span class="new_code">print_r()</span> formaté pour du déboguage rapide et grossier</td> +</tr> + </tbody></table> + </p> + + <h2> +<a class="target" name="extension_unitaire"></a>Etendre les scénarios de test</h2> + <p> + Bien sûr des méthodes supplémentaires de test + peuvent être ajoutées pour créer d'autres types + de scénario de test afin d'étendre le framework... +<pre> +require_once('simpletest/autorun.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> + Ici la bibliothèque SimpleTest est localisée + dans un répertoire local appelé <em>simpletest</em>. + Pensez à le modifier pour votre propre environnement. + </p> + <p> + Alternativement vous pourriez utiliser dans votre code + un directive <span class="new_code">SimpleTestOptions::ignore('FileTester');</span>. + </p> + <p> + Ce nouveau scénario peut être hérité exactement + comme un scénario de test classique... +<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> + Si vous souhaitez un scénario de test sans + toutes les assertions de <span class="new_code">UnitTestCase</span> + mais uniquement avec les vôtres propres, + vous aurez besoin d'étendre la classe + <span class="new_code">SimpleTestCase</span> à la place. + Elle se trouve dans <em>simple_test.php</em> + en lieu et place de <em>unit_tester.php</em>. + A consulter <a href="group_test_documentation.html">plus tard</a> + si vous souhaitez incorporer les scénarios + d'autres testeurs unitaires dans votre suite de test. + </p> + + <h2> +<a class="target" name="lancement_unitaire"></a>Lancer un unique scénario de test</h2> + <p> + Ce n'est pas souvent qu'il faille lancer des scénarios + avec un unique test. Sauf lorsqu'il s'agit de s'arracher + les cheveux sur un module à problème sans pour + autant désorganiser la suite de test principale. + Avec <em>autorun</em> aucun échafaudage particulier + n'est nécessaire, il suffit de lancer votre test et + vous y êtes. + </p> + <p> + Vous pouvez même décider quel rapporteur + (par exemple, <span class="new_code">TextReporter</span> ou <span class="new_code">HtmlReporter</span>) + vous préférez pour un fichier spécifique quand il est lancé + tout seul... +<pre> +<?php +require_once('simpletest/autorun.php');<strong> +SimpleTest :: prefer(new TextReporter());</strong> +require_once('../classes/writer.php'); + +class FileTestCase extends UnitTestCase { + ... +} +?> +</pre> + Ce script sera lancé tel que mais il n'y aura + aucun succès ou échec avant que des méthodes de test soient ajoutées. + </p> + + </div> + References and related information... + <ul> +<li> + La page de SimpleTest sur + <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page de téléchargement de SimpleTest sur + <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + <a href="http://simpletest.org/api/">L'API complète de SimpleTest</a> + à partir de PHPDoc. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> diff --git a/3rdparty/simpletest/docs/fr/web_tester_documentation.html b/3rdparty/simpletest/docs/fr/web_tester_documentation.html new file mode 100644 index 00000000000..308fbc9ccbb --- /dev/null +++ b/3rdparty/simpletest/docs/fr/web_tester_documentation.html @@ -0,0 +1,570 @@ +<html> +<head> +<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : tester des scripts web</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<h1>Documentation sur le testeur web</h1> + This page... + <ul> +<li> + Réussir à <a href="#telecharger">télécharger une page web</a> + </li> +<li> + Tester le <a href="#contenu">contenu de la page</a> + </li> +<li> + <a href="#navigation">Naviguer sur un site web</a> pendant le test + </li> +<li> + Méthodes pour <a href="#requete">modifier une requête</a> et pour déboguer + </li> +</ul> +<div class="content"> + <h2> +<a class="target" name="telecharger"></a>Télécharger une page</h2> + <p> + Tester des classes c'est très bien. + Reste que PHP est avant tout un langage + pour créer des fonctionnalités à l'intérieur de pages web. + Comment pouvons tester la partie de devant + -- celle de l'interface -- dans nos applications en PHP ? + Etant donné qu'une page web n'est constituée que de texte, + nous devrions pouvoir les examiner exactement + comme n'importe quelle autre donnée de test. + </p> + <p> + Cela nous amène à une situation délicate. + Si nous testons dans un niveau trop bas, + vérifier des balises avec un motif ad hoc par exemple, + nos tests seront trop fragiles. Le moindre changement + dans la présentation pourrait casser un grand nombre de test. + Si nos tests sont situés trop haut, en utilisant + une version fantaisie du moteur de template pour + donner un cas précis, alors nous perdons complètement + la capacité à automatiser certaines classes de test. + Par exemple, l'interaction entre des formulaires + et la navigation devra être testé manuellement. + Ces types de test sont extrêmement fastidieux + et plutôt sensibles aux erreurs. + </p> + <p> + SimpleTest comprend une forme spéciale de scénario + de test pour tester les actions d'une page web. + <span class="new_code">WebTestCase</span> inclut des facilités pour la navigation, + des vérifications sur le contenu + et les cookies ainsi que la gestion des formulaires. + Utiliser ces scénarios de test ressemble + fortement à <span class="new_code">UnitTestCase</span>... +<pre> +<strong>class TestOfLastcraft extends WebTestCase { +}</strong> +</pre> + Ici nous sommes sur le point de tester + le site de <a href="http://www.lastcraft.com/">Last Craft</a>. + Si ce scénario de test est situé dans un fichier appelé + <em>lastcraft_test.php</em> alors il peut être chargé + dans un script de lancement tout comme des tests unitaires... +<pre> +<?php +require_once('simpletest/autorun.php');<strong> +require_once('simpletest/web_tester.php');</strong> +SimpleTest::prefer(new TextReporter()); + +class WebTests extends TestSuite { + function WebTests() { + $this->TestSuite('Web site tests');<strong> + $this->addFile('lastcraft_test.php');</strong> + } +} +?> +</pre> + J'utilise ici le rapporteur en mode texte + pour mieux distinguer le contenu au format HTML + du résultat du test proprement dit. + </p> + <p> + Rien n'est encore testé. Nous pouvons télécharger + la page d'accueil en utilisant la méthode <span class="new_code">get()</span>... +<pre> +class TestOfLastcraft extends WebTestCase { + <strong> + function testHomepage() { + $this->assertTrue($this->get('http://www.lastcraft.com/')); + }</strong> +} +</pre> + La méthode <span class="new_code">get()</span> renverra "true" + uniquement si le contenu de la page a bien été téléchargé. + C'est un moyen simple, mais efficace pour vérifier + qu'une page web a bien été délivré par le serveur web. + Cependant le contenu peut révéler être une erreur 404 + et dans ce cas notre méthode <span class="new_code">get()</span> renverrait encore un succès. + </p> + <p> + En supposant que le serveur web pour le site Last Craft + soit opérationnel (malheureusement ce n'est pas toujours le cas), + nous devrions voir... +<pre class="shell"> +Web site tests +OK +Test cases run: 1/1, Failures: 0, Exceptions: 0 +</pre> + Nous avons vérifié qu'une page, de n'importe quel type, + a bien été renvoyée. Nous ne savons pas encore + s'il s'agit de celle que nous souhaitions. + </p> + + <h2> +<a class="target" name="contenu"></a>Tester le contenu d'une page</h2> + <p> + Pour obtenir la confirmation que la page téléchargée + est bien celle que nous attendions, + nous devons vérifier son contenu. +<pre> +class TestOfLastcraft extends WebTestCase { + + function testHomepage() {<strong> + $this->get('http://www.lastcraft.com/'); + $this->assertWantedPattern('/why the last craft/i');</strong> + } +} +</pre> + La page obtenue par le dernier téléchargement est + placée dans un buffer au sein même du scénario de test. + Il n'est donc pas nécessaire de s'y référer directement. + La correspondance du motif est toujours effectuée + par rapport à ce buffer. + </p> + <p> + Voici une liste possible d'assertions sur le contenu... + <table><tbody> + <tr> +<td><span class="new_code">assertWantedPattern($pattern)</span></td> +<td>Vérifier une correspondance sur le contenu via une expression rationnelle Perl</td> +</tr> + <tr> +<td><span class="new_code">assertNoUnwantedPattern($pattern)</span></td> +<td>Une expression rationnelle Perl pour vérifier une absence</td> +</tr> + <tr> +<td><span class="new_code">assertTitle($title)</span></td> +<td>Passe si le titre de la page correspond exactement</td> +</tr> + <tr> +<td><span class="new_code">assertLink($label)</span></td> +<td>Passe si un lien avec ce texte est présent</td> +</tr> + <tr> +<td><span class="new_code">assertNoLink($label)</span></td> +<td>Passe si aucun lien avec ce texte est présent</td> +</tr> + <tr> +<td><span class="new_code">assertLinkById($id)</span></td> +<td>Passe si un lien avec cet attribut d'identification est présent</td> +</tr> + <tr> +<td><span class="new_code">assertField($name, $value)</span></td> +<td>Passe si une balise input avec ce nom contient cette valeur</td> +</tr> + <tr> +<td><span class="new_code">assertFieldById($id, $value)</span></td> +<td>Passe si une balise input avec cet identifiant contient cette valeur</td> +</tr> + <tr> +<td><span class="new_code">assertResponse($codes)</span></td> +<td>Passe si la réponse HTTP trouve une correspondance dans la liste</td> +</tr> + <tr> +<td><span class="new_code">assertMime($types)</span></td> +<td>Passe si le type MIME se retrouve dans cette liste</td> +</tr> + <tr> +<td><span class="new_code">assertAuthentication($protocol)</span></td> +<td>Passe si l'authentification provoquée est de ce type de protocole</td> +</tr> + <tr> +<td><span class="new_code">assertNoAuthentication()</span></td> +<td>Passe s'il n'y pas d'authentification provoquée en cours</td> +</tr> + <tr> +<td><span class="new_code">assertRealm($name)</span></td> +<td>Passe si le domaine provoqué correspond</td> +</tr> + <tr> +<td><span class="new_code">assertHeader($header, $content)</span></td> +<td>Passe si une entête téléchargée correspond à cette valeur</td> +</tr> + <tr> +<td><span class="new_code">assertNoUnwantedHeader($header)</span></td> +<td>Passe si une entête n'a pas été téléchargé</td> +</tr> + <tr> +<td><span class="new_code">assertHeaderPattern($header, $pattern)</span></td> +<td>Passe si une entête téléchargée correspond à cette expression rationnelle Perl</td> +</tr> + <tr> +<td><span class="new_code">assertCookie($name, $value)</span></td> +<td>Passe s'il existe un cookie correspondant</td> +</tr> + <tr> +<td><span class="new_code">assertNoCookie($name)</span></td> +<td>Passe s'il n'y a pas de cookie avec un tel nom</td> +</tr> + </tbody></table> + Comme d'habitude avec les assertions de SimpleTest, + elles renvoient toutes "false" en cas d'échec + et "true" si c'est un succès. + Elles renvoient aussi un message de test optionnel : + vous pouvez l'ajouter dans votre propre message en utilisant "%s". + </p> + <p> + A présent nous pourrions effectué le test sur le titre uniquement... +<pre> +<strong>$this->assertTitle('The Last Craft?');</strong> +</pre> + En plus d'une simple vérification sur le contenu HTML, + nous pouvons aussi vérifier que le type MIME est bien d'un type acceptable... +<pre> +<strong>$this->assertMime(array('text/plain', 'text/html'));</strong> +</pre> + Plus intéressant encore est la vérification sur + le code de la réponse HTTP. Pareillement au type MIME, + nous pouvons nous assurer que le code renvoyé se trouve + bien dans un liste de valeurs possibles... +<pre> +class TestOfLastcraft extends WebTestCase { + + function testHomepage() { + $this->get('http://simpletest.sourceforge.net/');<strong> + $this->assertResponse(200);</strong> + } +} +</pre> + Ici nous vérifions que le téléchargement s'est + bien terminé en ne permettant qu'une réponse HTTP 200. + Ce test passera, mais ce n'est pas la meilleure façon de procéder. + Il n'existe aucune page sur <em>http://simpletest.sourceforge.net/</em>, + à la place le serveur renverra une redirection vers + <em>http://www.lastcraft.com/simple_test.php</em>. + <span class="new_code">WebTestCase</span> suit automatiquement trois + de ces redirections. Les tests sont quelque peu plus + robustes de la sorte. Surtout qu'on est souvent plus intéressé + par l'interaction entre les pages que de leur simple livraison. + Si les redirections se révèlent être digne d'intérêt, + il reste possible de les supprimer... +<pre> +class TestOfLastcraft extends WebTestCase { + + function testHomepage() {<strong> + $this->setMaximumRedirects(0);</strong> + $this->get('http://simpletest.sourceforge.net/'); + $this->assertResponse(200); + } +} +</pre> + Alors l'assertion échoue comme prévue... +<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> + Nous pouvons modifier le test pour accepter les redirections... +<pre> +class TestOfLastcraft extends WebTestCase { + + function testHomepage() { + $this->setMaximumRedirects(0); + $this->get('http://simpletest.sourceforge.net/'); + $this->assertResponse(<strong>array(301, 302, 303, 307)</strong>); + } +} +</pre> + Maitenant ça passe. + </p> + + <h2> +<a class="target" name="navigation"></a>Navigeur dans un site web</h2> + <p> + Les utilisateurs ne naviguent pas souvent en tapant les URLs, + mais surtout en cliquant sur des liens et des boutons. + Ici nous confirmons que les informations sur le contact + peuvent être atteintes depuis la page d'accueil... +<pre> +class TestOfLastcraft extends WebTestCase { + ... + function testContact() { + $this->get('http://www.lastcraft.com/');<strong> + $this->clickLink('About'); + $this->assertTitle('About Last Craft');</strong> + } +} +</pre> + Le paramètre est le texte du lien. + </p> + <p> + Il l'objectif est un bouton plutôt qu'une balise ancre, + alors <span class="new_code">clickSubmit()</span> doit être utilisé avec + le titre du bouton... +<pre> +<strong>$this->clickSubmit('Go!');</strong> +</pre> + </p> + <p> + La liste des méthodes de navigation est... + <table><tbody> + <tr> +<td><span class="new_code">get($url, $parameters)</span></td> +<td>Envoie une requête GET avec ces paramètres</td> +</tr> + <tr> +<td><span class="new_code">post($url, $parameters)</span></td> +<td>Envoie une requête POST avec ces paramètres</td> +</tr> + <tr> +<td><span class="new_code">head($url, $parameters)</span></td> +<td>Envoie une requête HEAD sans remplacer le contenu de la page</td> +</tr> + <tr> +<td><span class="new_code">retry()</span></td> +<td>Relance la dernière requête</td> +</tr> + <tr> +<td><span class="new_code">back()</span></td> +<td>Identique au bouton "Précédent" du navigateur</td> +</tr> + <tr> +<td><span class="new_code">forward()</span></td> +<td>Identique au bouton "Suivant" du navigateur</td> +</tr> + <tr> +<td><span class="new_code">authenticate($name, $password)</span></td> +<td>Re-essaye avec une tentative d'authentification</td> +</tr> + <tr> +<td><span class="new_code">getFrameFocus()</span></td> +<td>Le nom de la fenêtre en cours d'utilisation</td> +</tr> + <tr> +<td><span class="new_code">setFrameFocusByIndex($choice)</span></td> +<td>Change le focus d'une fenêtre en commençant par 1</td> +</tr> + <tr> +<td><span class="new_code">setFrameFocus($name)</span></td> +<td>Change le focus d'une fenêtre en utilisant son nom</td> +</tr> + <tr> +<td><span class="new_code">clearFrameFocus()</span></td> +<td>Revient à un traitement de toutes les fenêtres comme une seule</td> +</tr> + <tr> +<td><span class="new_code">clickSubmit($label)</span></td> +<td>Clique sur le premier bouton avec cette étiquette</td> +</tr> + <tr> +<td><span class="new_code">clickSubmitByName($name)</span></td> +<td>Clique sur le bouton avec cet attribut de nom</td> +</tr> + <tr> +<td><span class="new_code">clickSubmitById($id)</span></td> +<td>Clique sur le bouton avec cet attribut d'identification</td> +</tr> + <tr> +<td><span class="new_code">clickImage($label, $x, $y)</span></td> +<td>Clique sur une balise input de type image par son titre (title="*") our son texte alternatif (alt="*")</td> +</tr> + <tr> +<td><span class="new_code">clickImageByName($name, $x, $y)</span></td> +<td>Clique sur une balise input de type image par son attribut (name="*")</td> +</tr> + <tr> +<td><span class="new_code">clickImageById($id, $x, $y)</span></td> +<td>Clique sur une balise input de type image par son identifiant (id="*")</td> +</tr> + <tr> +<td><span class="new_code">submitFormById($id)</span></td> +<td>Soumet un formulaire sans valeur de soumission</td> +</tr> + <tr> +<td><span class="new_code">clickLink($label, $index)</span></td> +<td>Clique sur une ancre avec ce texte d'étiquette visible</td> +</tr> + <tr> +<td><span class="new_code">clickLinkById($id)</span></td> +<td>Clique sur une ancre avec cet attribut d'identification</td> +</tr> + </tbody></table> + </p> + <p> + Les paramètres dans les méthodes <span class="new_code">get()</span>, + <span class="new_code">post()</span> et <span class="new_code">head()</span> sont optionnels. + Le téléchargement via HTTP HEAD ne modifie pas + le contexte du navigateur, il se limite au chargement des cookies. + Cela peut être utilise lorsqu'une image ou une feuille de style + initie un cookie pour bloquer un robot trop entreprenant. + </p> + <p> + Les commandes <span class="new_code">retry()</span>, <span class="new_code">back()</span> + et <span class="new_code">forward()</span> fonctionnent exactement comme + dans un navigateur. Elles utilisent l'historique pour + relancer les pages. Une technique bien pratique pour + vérifier les effets d'un bouton retour sur vos formulaires. + </p> + <p> + Les méthodes sur les fenêtres méritent une petite explication. + Par défaut, une page avec des fenêtres est traitée comme toutes + les autres. Le contenu sera vérifié à travers l'ensemble de + la "frameset", par conséquent un lien fonctionnera, + peu importe la fenêtre qui contient la balise ancre. + Vous pouvez outrepassé ce comportement en exigeant + le focus sur une unique fenêtre. Si vous réalisez cela, + toutes les recherches et toutes les actions se limiteront + à cette unique fenêtre, y compris les demandes d'authentification. + Si un lien ou un bouton n'est pas dans la fenêtre en focus alors + il ne peut pas être cliqué. + </p> + <p> + Tester la navigation sur des pages fixes ne vous alerte que + quand vous avez cassé un script entier. + Pour des pages fortement dynamiques, + un forum de discussion par exemple, + ça peut être crucial pour vérifier l'état de l'application. + Pour la plupart des applications cependant, + la logique vraiment délicate se situe dans la gestion + des formulaires et des sessions. + Heureusement SimpleTest aussi inclut + <a href="form_testing_documentation.html"> + des outils pour tester des formulaires web</a>. + </p> + + <h2> +<a class="target" name="requete"></a>Modifier la requête</h2> + <p> + Bien que SimpleTest n'ait pas comme objectif + de contrôler des erreurs réseau, il contient quand même + des méthodes pour modifier et déboguer les requêtes qu'il lance. + Voici une autre liste de méthode... + <table><tbody> + <tr> +<td><span class="new_code">getTransportError()</span></td> +<td>La dernière erreur de socket</td> +</tr> + <tr> +<td><span class="new_code">getUrl()</span></td> +<td>La localisation courante</td> +</tr> + <tr> +<td><span class="new_code">showRequest()</span></td> +<td>Déverse la requête sortante</td> +</tr> + <tr> +<td><span class="new_code">showHeaders()</span></td> +<td>Déverse les entêtes d'entrée</td> +</tr> + <tr> +<td><span class="new_code">showSource()</span></td> +<td>Déverse le contenu brut de la page HTML</td> +</tr> + <tr> +<td><span class="new_code">ignoreFrames()</span></td> +<td>Ne recharge pas les framesets</td> +</tr> + <tr> +<td><span class="new_code">setCookie($name, $value)</span></td> +<td>Initie un cookie à partir de maintenant</td> +</tr> + <tr> +<td><span class="new_code">addHeader($header)</span></td> +<td>Ajoute toujours cette entête à la requête</td> +</tr> + <tr> +<td><span class="new_code">setMaximumRedirects($max)</span></td> +<td>S'arrête après autant de redirections</td> +</tr> + <tr> +<td><span class="new_code">setConnectionTimeout($timeout)</span></td> +<td>Termine la connexion après autant de temps entre les bytes</td> +</tr> + <tr> +<td><span class="new_code">useProxy($proxy, $name, $password)</span></td> +<td>Effectue les requêtes à travers ce proxy d'URL</td> +</tr> + </tbody></table> + </p> + + </div> + References and related information... + <ul> +<li> + La page du projet SimpleTest sur + <a href="http://sourceforge.net/projects/simpletest/">SourceForge</a>. + </li> +<li> + La page de téléchargement de SimpleTest sur + <a href="http://www.lastcraft.com/simple_test.php">LastCraft</a>. + </li> +<li> + <a href="http://simpletest.org/api/">L'API du développeur pour SimpleTest</a> + donne tous les détails sur les classes et les assertions disponibles. + </li> +</ul> +<div class="menu_back"><div class="menu"> +<a href="index.html">SimpleTest</a> + | + <a href="overview.html">Overview</a> + | + <a href="unit_test_documentation.html">Unit tester</a> + | + <a href="group_test_documentation.html">Group tests</a> + | + <a href="mock_objects_documentation.html">Mock objects</a> + | + <a href="partial_mocks_documentation.html">Partial mocks</a> + | + <a href="reporter_documentation.html">Reporting</a> + | + <a href="expectation_documentation.html">Expectations</a> + | + <a href="web_tester_documentation.html">Web tester</a> + | + <a href="form_testing_documentation.html">Testing forms</a> + | + <a href="authentication_documentation.html">Authentication</a> + | + <a href="browser_documentation.html">Scriptable browser</a> +</div></div> +<div class="copyright"> + Copyright<br>Marcus Baker 2006 + </div> +</body> +</html> |