diff options
Diffstat (limited to 'tests/test_tools/simpletest/docs/fr')
14 files changed, 4293 insertions, 0 deletions
diff --git a/tests/test_tools/simpletest/docs/fr/authentication_documentation.html b/tests/test_tools/simpletest/docs/fr/authentication_documentation.html new file mode 100755 index 00000000..08cc2349 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/authentication_documentation.html @@ -0,0 +1,264 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur l'authentification</h1> +<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> + + <p> +<a class="target" name="basique"> +<h2>Authentification HTTP basique</h2> +</a> +</p> + <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> + 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. + </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> + 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> + + <p> +<a class="target" name="cookies"> +<h2>Cookies</h2> +</a> +</p> + <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 vaut pas la peine d'être testée. + </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> + + <p> +<a class="target" name="session"> +<h2>Sessions de navigateur</h2> +</a> +</p> + <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 a expiré, mais conserve 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> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/browser_documentation.html b/tests/test_tools/simpletest/docs/fr/browser_documentation.html new file mode 100755 index 00000000..fa8ad1b6 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/browser_documentation.html @@ -0,0 +1,329 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur le navigateur scriptable</h1> +<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 frameword SimpleTest lui-même. + </p> + + <p> +<a class="target" name="script"> +<h2>Le navigateur scriptable</h2> +</a> +</p> + <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 formulaire et la capacité d'examiner les entêtes. De telles méthodes 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">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 si un lien avec cette étiquette existe</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 si un lien avec cet attribut d'identification existe</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 appellé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($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($name)</span></td><td>Accesseur de la valeur d'un élément de formulaire</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 l'image par son texte alternatif</td> +</tr> + <tr> +<td><span class="new_code">clickImageByName($name, $x, $y)</span></td><td>Clique sur l'image par son attribut</td> +</tr> + <tr> +<td><span class="new_code">clickImageById($id, $x, $y)</span></td><td>Clique sur l'image par son identifiant</td> +</tr> + <tr> +<td><span class="new_code">submitFormById($id)</span></td><td>Transmet le formulaire par son identifiant propre</td> +</tr> + </tbody> +</table> + A aujourd'hui il n'existe aucune méthode pour lister les formulaires et les champs disponibles : 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 un 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> + + <p> +<a class="target" name="deboguer"> +<h2>Où sont les erreurs ?</h2> +</a> +</p> + <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">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'authenficiation 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">setMaximumRedirects($max)</span></td><td>Nombre de redirection 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 individuel 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> + + <p> +<a class="target" name="unit"> +<h2>Tests unitaires complexes avec des navigateurs multiples</h2> +</a> +</p> + <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> +class TestOfRegistration extends UnitTestCase { + function testNewUserAddedToAuthenticator() { + $browser = &new SimpleBrowser(); + $browser->get('http://my-site.com/register.php'); + $browser->setField('email', 'me@here'); + $browser->setField('password', 'Secret'); + $browser->clickSubmit('Register'); + + $authenticator = &new Authenticator(); + $member = &$authenticator->findByEmail('me@here'); + $this->assertEqual($member->getPassword(), 'Secret'); + } +} +</pre> + Bien que ça puisse être utile par convenance temporaire, je ne suis pas fan de ce genre de test. Ce test s'applique à sur plusieurs couches de l'application, ça implique qu'il est plus que probable qu'il faudra le remanier lorsque le code change. + </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. + </p> + + </div> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/docs.css b/tests/test_tools/simpletest/docs/fr/docs.css new file mode 100755 index 00000000..93226cd7 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/docs.css @@ -0,0 +1,84 @@ +body { + padding-left: 3%; + padding-right: 3%; +} +pre { + font-family: courier; + font-size: 80%; + border: 1px solid; + background-color: #cccccc; + padding: 5px; + margin-left: 5%; + margin-right: 8%; +} +.code, .new_code, pre.new_code { + font-weight: bold; +} +div.copyright { + font-size: 80%; + color: gray; +} +div.copyright a { + color: gray; +} +ul.api { + padding-left: 0em; + padding-right: 25%; +} +ul.api li { + margin-top: 0.2em; + margin-bottom: 0.2em; + list-style: none; + text-indent: -3em; + padding-left: 3em; +} +div.demo { + border: 4px ridge; + border-color: gray; + padding: 10px; + margin: 5px; + margin-left: 20px; + margin-right: 40px; + background-color: white; +} +div.demo span.fail { + color: red; +} +div.demo span.pass { + color: green; +} +div.demo h1 { + font-size: 12pt; + text-align: left; + font-weight: bold; +} +table { + border: 2px outset; + border-color: gray; + background-color: white; + margin: 5px; + margin-left: 5%; + margin-right: 5%; +} +td { + font-size: 80%; +} +.shell { + color: white; +} +pre.shell { + border: 4px ridge; + border-color: gray; + padding: 10px; + margin: 5px; + margin-left: 20px; + margin-right: 40px; + background-color: black; +} +form.demo { + background-color: lightgray; + border: 4px outset; + border-color: lightgray; + padding: 10px; + margin-right: 40%; +} diff --git a/tests/test_tools/simpletest/docs/fr/expectation_documentation.html b/tests/test_tools/simpletest/docs/fr/expectation_documentation.html new file mode 100755 index 00000000..ab9ef606 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/expectation_documentation.html @@ -0,0 +1,263 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur les attentes</h1> +<div class="content"> + <p> +<a class="target" name="fantaisie"> +<h2>Plus de contrôle sur les objets fantaisie</h2> +</a> +</p> + <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 WantedPatternExpectation('/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">WantedPatternExpectation</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">WantedPatternExpectation</span> utilise l'expression rationnelle pour la comparaison avec son constructeur. A chaque fois q'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">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">WantedPatternExpectation</span></td><td>Utilise une expression rationnelle Perl pour comparer une chaîne</td> +</tr> + <tr> +<td><span class="new_code">NoUnwantedPatternExpectation</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> + </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> + + <p> +<a class="target" name="comportement"> +<h2>Utiliser les attentes pour contrôler les bouchons serveur</h2> +</a> +</p> + <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> our 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 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->setReturnValue( + 'isAllowed', + true, + array(new IsAExpectation('Session', 'Must be a session'))); +$authorisation->setReturnValue('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> + + <p> +<a class="target" name="etendre"> +<h2>Créer vos propres attentes</h2> +</a> +</p> + <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>... +<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> +<a class="target" name="unitaire"> +<h2>Sous le capot du testeur unitaire</h2> +</a> +</p> + <p> + Le <a href="http://sourceforge.net/projects/simpletest/">frameworkd 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::assertExpectation()</span> pour effectuer le test... +<pre> +<strong>class TestOfNetworking extends UnitTestCase { + ... + function testGetValidIp() { + $server = &new Server(); + $this->assertExpectation( + new ValidIp(), + $server->getIp(), + 'Server IP address->%s'); + } +}</strong> +</pre> + 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> + Il est peu probable que nous ayons besoin de ce niveau de contrôle sur la machinerie de test. Il est assez rare que le besoin d'une attente dépasse le stade de la reconnaissance d'un motif. De plus, 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> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/form_testing_documentation.html b/tests/test_tools/simpletest/docs/fr/form_testing_documentation.html new file mode 100755 index 00000000..f9f5d0df --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/form_testing_documentation.html @@ -0,0 +1,235 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur les tests de formulaire</h1> +<div class="content"> + <p> +<a class="target" name="submit"> +<h2>Valider un formulaire simple</h2> +</a> +</p> + <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 pas 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, mais d'abord nous allons changer la valeur du champ texte. Ce n'est qu'après que nous le transmettre... +<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. 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. + </p> + <p> + Si un champ manque dans n'importe que 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 suite à un échec d'initialisation d'une valeur sur un objet. + </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> + Bien que la plupart des objets HTML standards soient couvert par le parseur de <em>SimpleTest</em>, il est peu probable que JavaScript soit implémenté dans un futur proche. + </p> + + <p> +<a class="target" name="multiple"> +<h2>Champs à valeurs multiples</h2> +</a> +</p> + <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'autre code de test pour confirmer cet effet, peut-être en nous connectant comme utilisateur et en essayant d'effectuer une mise à jour. + </p> + <p> + <a class="target" name="brut"> +<h2>Envoi brut</h2> +</a> + </p> + <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 essayons de télécharger la page via la transmission d'un formulaire. + </p> + + </div> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/group_test_documentation.html b/tests/test_tools/simpletest/docs/fr/group_test_documentation.html new file mode 100755 index 00000000..662f868e --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/group_test_documentation.html @@ -0,0 +1,288 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur le groupement des tests</h1> +<div class="content"> + <p> +<a class="target" name="grouper"> +<h2>Grouper des tests</h2> +</a> +</p> + <p> + Pour lancer les scénarios de tests en tant que groupe, ils devraient être placés dans des fichiers sans le code du lanceur... +<pre> +<strong><?php + require_once('../classes/io.php'); + + class FileTester extends UnitTestCase { + ... + } + + class SocketTester extends UnitTestCase { + ... + } +?></strong> +</pre> + Autant de scénarios que nécessaires peuvent être mis dans un fichier unique. Ils doivent contenir tout le code nécessaire, entre autres la bibliothèque testée, mais aucune des bibliothèques de SimpleTest. + </p> + <p> + Si vous avez étendu l'un ou l'autre des scénarios de test, vous pouvez aussi les inclure. +<pre> +<?php + require_once('../classes/io.php'); +<strong> + class MyFileTestCase extends UnitTestCase { + ... + } + SimpleTestOptions::ignore('MyFileTestCase');</strong> + + 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. Pour cette raison nous utilisons la directive <span class="new_code">SimpleTestOptions::ignore()</span> pour indiquer au prochain groupe de test de l'ignorer. Cette directive peut se placer n'importe où dans le fichier et fonctionne quand un fichier complet des scénarios de test est chargé (cf. ci-dessous). Nous l'appelons <em>file_test.php</em>. + </p> + <p> + Ensuite nous créons un fichier de groupe de test, disons <em>group_test.php</em>. Vous penserez à un nom plus convaincant, j'en suis sûr. Nous lui ajoutons le fichier de test avec une méthode sans risque... +<pre> +<?php + require_once('simpletest/unit_tester.php'); + require_once('simpletest/reporter.php');<strong> + require_once('file_test.php'); + + $test = &new GroupTest('All file tests'); + $test->addTestCase(new FileTestCase()); + $test->run(new HtmlReporter());</strong> +?> +</pre> + Ceci instancie le scénario de test avant que la suite de test ne soit lancée. Ça pourrait devenir assez onéreux avec un grand nombre de scénarios de test : il existe donc une autre méthode qui instancie la classe uniquement quand elle devient nécessaire... +<pre> +<?php + require_once('simpletest/unit_tester.php'); + require_once('simpletest/reporter.php'); + require_once('file_test.php'); + + $test = &new GroupTest('All file tests');<strong> + $test->addTestClass('FileTestCase');</strong> + $test->run(new HtmlReporter()); +?> +</pre> + Le problème de cette technique est que pour chaque scénario de test supplémentaire nous aurons à <span class="new_code">require_once()</span> le fichier de code de test et à manuellement instancier chaque scénario de test. Nous pouvons nous épargner beaucoup de dactylographie avec... +<pre> +<?php + require_once('simpletest/unit_tester.php'); + require_once('simpletest/reporter.php'); + + $test = &new GroupTest('All file tests');<strong> + $test->addTestFile('file_test.php');</strong> + $test->run(new HtmlReporter()); +?&gt; +</pre> + Voici ce qui vient de se passer : la classe <span class="new_code">GroupTest</span> a réalisé le <span class="new_code">require_once()</span> pour nous. Ensuite elle vérifie si de nouvelles classes de scénario de test ont été créées par ce nouveau fichier et les ajoute automatiquement au groupe de test. Désormais tout ce qu'il nous reste à faire, c'est d'ajouter chaque nouveau fichier. + </p> + <p> + Il y a deux choses qui peuvent planter et qui demandent un minimum d'attention... + <ol> + <li> + Le fichier peut déjà avoir été analysé par PHP et dans ce cas aucune classe ne sera ajoutée. Pensez à bien vérifier que les scénarios de test ne sont inclus que dans ce fichier et dans aucun autre. + </li> + <li> + Les nouvelles classes d'extension de scénario de test qui sont incluses seront placées dans le groupe de test et exécutées par la même occasion. Vous aurez à ajouter une directive <span class="new_code">SimpleTestOptions::ignore()</span> pour ces classes ou alors pensez à les ajouter avant la ligne <span class="new_code">GroupTest::addTestFile()</span>. + </li> + </ol> + </p> + + <p> +<a class="target" name="plus-haut"> +<h2>Groupements de plus haut niveau</h2> +</a> +</p> + <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> + Pour obtenir un groupe de test plus souple nous pouvons sous classer <span class="new_code">GroupTest</span> et ensuite l'instancier au cas par cas... +<pre> +<?php + require_once('simpletest/unit_tester.php'); + require_once('simpletest/reporter.php'); + <strong> + class FileGroupTest extends GroupTest { + function FileGroupTest() { + $this->GroupTest('All file tests'); + $this->addTestFile('file_test.php'); + } + }</strong> +?> +</pre> + Ceci nomme le test dans le constructeur et ensuite ajoute à la fois nos scénarios de test et un unique groupe en dessous. Bien sûr nous pouvons ajouter plus d'un groupe à cet instant. Nous pouvons maintenant invoquer les tests à partir d'un autre fichier d'exécution... +<pre> +<?php + require_once('file_group_test.php'); + <strong> + $test = &new FileGroupTest(); + $test->run(new HtmlReporter());</strong> +?> +</pre> + ...ou alors nous pouvons les grouper dans un groupe de tests encore plus grand... +<pre> +<?php + require_once('file_group_test.php'); + <strong> + $test = &new BigGroupTest('Big group'); + $test->addTestCase(new FileGroupTest()); + $test->addTestCase(...); + $test->run(new HtmlReporter());</strong> +?> +</pre> + Si nous souhaitons lancer le groupe de test original sans utiliser ses petits fichiers d'exécution, nous pouvons mettre le code du lanceur de test derrière des barreaux quand nous créons chaque groupe. +<pre> +<?php + class FileGroupTest extends GroupTest { + function FileGroupTest() { + $this->GroupTest('All file tests'); + $test->addTestFile('file_test.php'); + } + } + <strong> + if (! defined('RUNNER')) { + define('RUNNER', true);</strong> + $test = &new FileGroupTest(); + $test->run(new HtmlReporter()); + } +?> +</pre> + Cette approche exige aux barrières d'être activées à l'inclusion du fichier de groupe de test, mais c'est quand même moins de tracas que beaucoup de fichiers de lancement éparpillés. Reste à inclure des barreaux identiques au niveau supérieur afin de s'assurer que le <span class="new_code">run()</span> ne sera lancé qu'une seule fois à partir du script de haut niveau qui l'a invoqué. +<pre> +<?php + define('RUNNER', true); + + require_once('file_group_test.php'); + $test = &new BigGroupTest('Big group'); + $test->addTestCase(new FileGroupTest()); + $test->addTestCase(...); + $test->run(new HtmlReporter()); +?> +</pre> + Comme les scénarios de test normaux, un <span class="new_code">GroupTest</span> peut être chargé avec la méthode <span class="new_code">GroupTest::addTestFile()</span>. +<pre> +<?php + define('RUNNER', true); + + $test = &new BigGroupTest('Big group');<strong> + $test->addTestFile('file_group_test.php'); + $test->addTestFile(...);</strong> + $test->run(new HtmlReporter()); +?> +</pre> + </p> + + <p> +<a class="target" name="heritage"> +<h2>Intégrer des scénarios de test hérités</h2> +</a> +</p> + <p> + Si vous avez déjà des tests unitaires pour votre code ou alors si vous étendez des classes externes qui ont déjà leurs propres tests, il y a peu de chances pour que ceux-ci soient déjà au format SimpleTest. Heureusement il est possible d'incorporer ces scénarios de test en provenance d'autres testeurs unitaires directement dans des groupes de test SimpleTest. + </p> + <p> + Par exemple, supposons que nous ayons ce scénario de test prévu pour <a href="http://sourceforge.net/projects/phpunit">PhpUnit</a>dans le fichier <em>config_test.php</em>... +<pre> +<strong>class ConfigFileTest extends TestCase { + function ConfigFileTest() { + $this->TestCase('Config file test'); + } + + function testContents() { + $config = new ConfigFile('test.conf'); + $this->assertRegexp('/me/', $config->getValue('username')); + } +}</strong> +</pre> + Le groupe de test peut le reconnaître à partir du moment où nous mettons l'adaptateur approprié avant d'ajouter le fichier de test... +<pre> +<?php + require_once('simpletest/unit_tester.php'); + require_once('simpletest/reporter.php');<strong> + require_once('simpletest/adapters/phpunit_test_case.php');</strong> + + $test = &new GroupTest('All file tests');<strong> + $test->addTestFile('config_test.php');</strong> + $test->run(new HtmlReporter()); +?> +</pre> + Il n'y a que deux adaptateurs, l'autre est pour le paquet testeur unitaire de <a href="http://pear.php.net/manual/en/package.php.phpunit.php">PEAR</a>... +<pre> +<?php + require_once('simpletest/unit_tester.php'); + require_once('simpletest/reporter.php');<strong> + require_once('simpletest/adapters/pear_test_case.php');</strong> + + $test = &new GroupTest('All file tests');<strong> + $test->addTestFile('some_pear_test_cases.php');</strong> + $test->run(new HtmlReporter()); +?> +</pre> + Les scénarios de test de PEAR peuvent être librement mélangés avec ceux de SimpleTest mais vous ne pouvez pas utiliser les assertions de SimpleTest au sein des versions héritées des scénarios de test. La raison ? Une simple vérification que vous ne rendez pas par accident vos scénarios de test complètement dépendants de SimpleTest. Peut-être que vous souhaitez publier votre bibliothèque sur PEAR par exemple : ça voudrait dire la livrer avec des scénarios de test compatibles avec PEAR::PhpUnit. + </p> + + </div> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/index.html b/tests/test_tools/simpletest/docs/fr/index.html new file mode 100755 index 00000000..f4b2ad93 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/index.html @@ -0,0 +1,343 @@ +<html> +<head> +<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title> + Télécharger le framework de tests Simple Test - 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"> +<h2> +<span class="chosen">SimpleTest</span> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Simple Test pour PHP</h1> +<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> + + <p> +<a class="target" name="unit"> +<h2>Utiliser le testeur rapidement</h2> +</a> +</p> + <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>. Sans compter quelques fonctionnalités de <a href="http://sourceforge.net/projects/jwebunit/">JWebUnit</a> : parmi celles-ci la navigation sur des pages web, les tests sur les cookies et l'envoi de formulaire. + </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> +<strong><?php +require_once('simpletest/unit_tester.php'); +require_once('simpletest/reporter.php'); +require_once('../classes/log.php'); +?></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. Ensuite créons un scénario de test... +<pre> +<?php +require_once('simpletest/unit_tester.php'); +require_once('simpletest/reporter.php'); +require_once('../classes/log.php'); +<strong> +class TestOfLogging extends UnitTestCase { +}</strong> +?> +</pre> + A présent il y a 5 lignes de code d'échafaudage et toujours pas de test. Cependant à partir de cet instant le retour sur investissement arrive très rapidement. Supposons que la classe <span class="new_code">Log</span> prenne le nom du fichier à écrire dans le constructeur et que nous ayons un répertoire temporaire dans lequel placer ce fichier... +<pre> +<?php +require_once('simpletest/unit_tester.php'); +require_once('simpletest/reporter.php'); +require_once('../classes/log.php'); + +class TestOfLogging extends UnitTestCase { + <strong> + function testCreatingNewFile() { + @unlink('/temp/test.log'); + $log = new Log('/temp/test.log'); + $this->assertFalse(file_exists('/temp/test.log')); + $log->message('Should write this to a file'); + $this->assertTrue(file_exists('/temp/test.log')); + }</strong> +} +?> +</pre> + 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. D'ordinaire nous avons bien plusieurs méthodes de tests. 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é. + </p> + <p> + Pour voir ces résultats lançons effectivement les tests. S'il s'agit de l'unique scénario de test à lancer, on peut y arriver avec... +<pre> +<?php +require_once('simpletest/unit_tester.php'); +require_once('simpletest/reporter.php'); +require_once('../classes/log.php'); + +class TestOfLogging extends UnitTestCase { + + function testCreatingNewFile() { + @unlink('/temp/test.log'); + $log = new Log('/temp/test.log'); + $this->assertFalse(file_exists('/temp/test.log')); + $log->message('Should write this to a file'); + $this->assertTrue(file_exists('/temp/test.log')); + } +} +<strong> +$test = &new TestOfLogging(); +$test->run(new HtmlReporter());</strong> +?> +</pre> + </p> + <p> + 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 +class Log { + + function Log($file_path) { + } +} +?>; +</pre> + </p> + + <p> +<a class="target" name="group"> +<h2>Construire des groupes de tests</h2> +</a> +</p> + <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 supprimer les includes et de défaire notre hack précédent... +<pre> +<?php<strong> +require_once('../classes/log.php');</strong> + +class TestOfLogging extends UnitTestCase { + + function testCreatingNewFile() { + @unlink('/temp/test.log'); + $log = new Log('/temp/test.log'); + $this->assertFalse(file_exists('/temp/test.log')); + $log->message('Should write this to a file'); + $this->assertTrue(file_exists('/temp/test.log'));<strong> + } +} +?></strong> +</pre> + Ensuite nous créons un nouveau fichier appelé <em>tests/all_tests.php</em>. On y insert le code suivant... +<pre> +<strong><?php +require_once('simpletest/unit_tester.php'); +require_once('simpletest/reporter.php'); + +$test = &new GroupTest('All tests'); +$test->addTestFile('log_test.php'); +$test->run(new HtmlReporter()); +?></strong> +</pre> + Cette méthode <span class="new_code">GroupTest::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">TestCase</span>. Dans un premier temps, seuls les noms sont stockés, de la sorte le lanceur de test peut instancier la classe au fur et à mesure qu'il exécute votre suite de tests. + </p> + <p> + Pour que ça puisse marcher proprement le fichier de suite de tests ne devrait pas inclure aveuglement d'autres extensions de scénarios de test qui n'exécuteraient pas effectivement de test. Le résultat pourrait être que des tests supplémentaires soient alors être comptabilisés pendant l'exécution des tests. Ce n'est pas un problème grave mais pour éviter ce désagrément, il suffit d'ajouter la commande <span class="new_code">SimpleTestOptions::ignore()</span> quelque part dans le fichier de scénario de test. Par ailleurs le scénario de test ne devrait pas avoir été inclus ailleurs ou alors aucun scénario ne sera ajouté aux groupes de test. Il s'agirait là d'une erreur autrement sérieuse : si tous les classes de scénario de test sont chargées par PHP, alors la méthode <span class="new_code">GroupTest::addTestFile()</span> ne pourra pas les détecter. + </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> +<a class="target" name="mock"> +<h2>Utiliser les objets fantaisie</h2> +</a> +</p> + <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> +<strong> +<?php +require_once('../classes/log.php'); +require_once('../classes/session_pool.php'); + +class TestOfSessionLogging extends UnitTestCase { + + function setUp() { + @unlink('/temp/test.log'); + } + + function tearDown() { + @unlink('/temp/test.log'); + } + + function testLogInIsLogged() { + $log = new Log('/temp/test.log'); + $session_pool = &new SessionPool($log); + $session_pool->logIn('fred'); + $messages = file('/temp/test.log'); + $this->assertEqual($messages[0], "User fred logged in.\n"); + } +} +?></strong> +</pre> + 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 ? 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 réduisons 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 ? Par chance on peut créer un tel objet très facilement... +<pre> +<?php +require_once('../classes/log.php'); +require_once('../classes/session_pool.php');<strong> +Mock::generate('Log');</strong> + +class TestOfSessionLogging extends UnitTestCase { + + function testLogInIsLogged() {<strong> + $log = &new MockLog($this); + $log->expectOnce('message', array('User fred logged in.'));</strong> + $session_pool = &new SessionPool($log); + $session_pool->logIn('fred');<strong> + $log->tally();</strong> + } +} +?> +</pre> + 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>. 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 ici aussi afin d'empêcher que les tests ne deviennent trop spécifiques. + </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> +<a class="target" name="web"> +<h2>Tester une page web</h2> +</a> +</p> + <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. 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<strong> +require_once('simpletest/web_tester.php');</strong> +require_once('simpletest/reporter.php'); +<strong> +class TestOfAbout extends WebTestCase { + + function setUp() { + $this->get('http://test-server/index.php'); + $this->clickLink('About'); + } + + function testSearchEngineOptimisations() { + $this->assertTitle('A long title about us for search engines'); + $this->assertWantedPattern('/a popular keyphrase/i'); + } +}</strong> +$test = &new TestOfAbout(); +$test->run(new HtmlReporter()); +?> +</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> + <a href="http://sourceforge.net/projects/simpletest/"><img src="http://sourceforge.net/sflogo.php?group_id=76550&type=5" width="210" height="62" border="0" alt="SourceForge.net Logo"></a> + </p> + + </div> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/mock_objects_documentation.html b/tests/test_tools/simpletest/docs/fr/mock_objects_documentation.html new file mode 100755 index 00000000..0ce48bc9 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/mock_objects_documentation.html @@ -0,0 +1,492 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur les objets fantaisie</h1> +<div class="content"> + <p> +<a class="target" name="quoi"> +<h2>Que sont les objets fantaisie ?</h2> +</a> +</p> + <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>. + </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. 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> + + <p> +<a class="target" name="creation"> +<h2>Créer des objets fantaisie</h2> +</a> +</p> + <p> + Comme pour la création des bouchons serveur, tout ce dont nous avons besoin c'est d'un classe existante. La fameuse connexion à une base de données qui ressemblerait à... +<pre> +<strong>class DatabaseConnection { + function DatabaseConnection() { + } + + function query() { + } + + function selectQuery() { + } +}</strong> +</pre> + Cette classe n'a pas encore besoin d'être implémentée. Pour en créer sa version fantaisie nous devons juste inclure la librairie d'objet fantaisie puis lancer le générateur... +<pre> +<strong>require_once('simpletest/unit_tester.php'); +require_once('simpletest/mock_objects.php'); +require_once('database_connection.php'); + +Mock::generate('DatabaseConnection');</strong> +</pre> + Ceci génère une classe clone appelée <span class="new_code">MockDatabaseConnection</span>. 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/unit_tester.php'); +require_once('simpletest/mock_objects.php'); +require_once('database_connection.php'); + +Mock::generate('DatabaseConnection'); +<strong> +class MyTestCase extends UnitTestCase { + + function testSomething() { + $connection = &new MockDatabaseConnection($this); + } +}</strong> +</pre> + Contrairement aux bouchons, le constructeur d'une classe fantaisie a besoin d'une référence au scénario de test pour pouvoir transmettre les succès et les échecs pendant qu'il vérifie les attentes. Concrètement ça veut dire que les objets fantaisie ne peuvent être utilisés qu'au sein d'un scénario de test. Malgré tout, cette puissance supplémentaire implique que les bouchons ne sont que rarement utilisés si des objets fantaisie sont disponibles. + </p> + <p> + <a class="target" name="bouchon"> +<h2>Objets fantaisie en action</h2> +</a> + </p> + <p> + La version fantaisie d'une classe contient toutes les méthodes de l'originale. De la sorte une opération comme <span class="new_code">$connection->query()</span> est encore possible. Tout comme avec les bouchons, nous pouvons remplacer la valeur nulle renvoyée par défaut... +<pre> +<strong>$connection->setReturnValue('query', 37);</strong> +</pre> + Désormais à chaque appel de <span class="new_code">$connection->query()</span> nous recevons comme résultat 37. Tout comme avec les bouchons nous pouvons utiliser des jokers et surcharger le paramètre joker. Nous pouvons aussi ajouter des méthodes supplémentaires à l'objet fantaisie lors de sa génération et lui choisir un nom de classe qui lui soit propre... +<pre> +<strong>Mock::generate('DatabaseConnection', 'MyMockDatabaseConnection', array('setOptions'));</strong> +</pre> + Ici l'objet fantaisie se comportera comme si <span class="new_code">setOptions()</span> existait dans la classe originale. C'est pratique si une classe a utilisé le mécanisme <span class="new_code">overload()</span> de PHP pour ajouter des méthodes dynamiques. Vous pouvez créer des fantaisies spéciales pour simuler cette situation. + </p> + <p> + Tous les modèles disponibles avec les bouchons serveur le sont également avec les objets fantaisie... +<pre> +class Iterator { + function Iterator() { + } + + function next() { + } +} +</pre> + Une nouvelle fois, supposons que cet itérateur ne retourne que du texte jusqu'au moment où il atteint son terme, quand il renvoie <span class="new_code">false</span>. Nous pouvons le simuler avec... +<pre> +Mock::generate('Iterator'); + +class IteratorTest extends UnitTestCase() { + + function testASequence() {<strong> + $iterator = &new MockIterator($this); + $iterator->setReturnValue('next', false); + $iterator->setReturnValueAt(0, 'next', 'First string'); + $iterator->setReturnValueAt(1, 'next', 'Second string');</strong> + ... + } +} +</pre> + Au moment du premier appel à <span class="new_code">next()</span> sur l'itérateur fantaisie il renverra tout d'abord "First string", puis ce sera au tour de "Second string" au deuxième appel et ensuite pour tout appel suivant <span class="new_code">false</span> sera renvoyé. Ces valeurs renvoyées successivement sont prioritaires sur la valeur constante retournée. Cette dernière est un genre de valeur par défaut si vous voulez. + </p> + <p> + Reprenons aussi le conteneur d'information bouchonné avec des pairs clef / valeur... +<pre> +class Configuration { + function Configuration() { + } + + function getValue($key) { + } +} +</pre> + Il s'agit là d'une situation classique d'utilisation d'objets fantaisie étant donné que la configuration peut varier grandement de machine à machine : ça contraint fortement la fiabilité de nos tests si nous l'utilisons directement. Le problème est que toutes les données nous parviennent à travers la méthode <span class="new_code">getValue()</span> et que nous voulons des résultats différents pour des clefs différentes. Heureusement les objets fantaisie ont un système de filtrage... +<pre> +<strong>$config = &new MockConfiguration($this); +$config->setReturnValue('getValue', 'primary', array('db_host')); +$config->setReturnValue('getValue', 'admin', array('db_user')); +$config->setReturnValue('getValue', 'secret', array('db_password'));</strong> +</pre> + Le paramètre en plus est une liste d'arguments à faire correspondre. Dans ce cas nous essayons de faire correspondre un unique argument : en l'occurrence la clef recherchée. Maintenant que la méthode <span class="new_code">getValue()</span> est invoquée sur l'objet fantaisie... +<pre> +$config->getValue('db_user') +</pre> + ...elle renverra "admin". Elle le trouve en essayant de faire correspondre les arguments entrants dans sa liste d'arguments sortants les uns après les autres jusqu'au moment où une correspondance exacte est atteinte. + </p> + <p> + Il y a des fois où vous souhaitez qu'un objet spécifique soit servi par la fantaisie plutôt qu'une copie. De nouveau c'est identique au mécanisme des bouchons serveur... +<pre> +class Thing { +} + +class Vector { + function Vector() { + } + + function get($index) { + } +} +</pre> + Dans ce cas vous pouvez placer une référence dans la liste renvoyée par l'objet fantaisie... +<pre> +$thing = new Thing();<strong> +$vector = &new MockVector($this); +$vector->setReturnReference('get', $thing, array(12));</strong> +</pre> + Avec cet arrangement vous savez qu'à chaque appel de <span class="new_code">$vector->get(12)</span> le même <span class="new_code">$thing</span> sera renvoyé. + </p> + + <p> +<a class="target" name="attentes"> +<h2>Objets fantaisie en critique</h2> +</a> +</p> + <p> + Même si les bouchons serveur vous isolent du désordre du monde réel, il ne s'agit là que de la moitié du bénéfice potentiel. Vous pouvez avoir une classe de test recevant les messages ad hoc, mais est-ce que votre nouvelle classe renvoie bien les bons ? Le tester peut devenir cafouillis sans une librairie d'objets fantaisie. + </p> + <p> + Pour l'exemple, prenons une classe <span class="new_code">SessionPool</span> à laquelle nous allons ajouter une fonction de log. Plutôt que de complexifier la classe originale, nous souhaitons ajouter ce comportement avec un décorateur (GOF). Pour l'instant le code de <span class="new_code">SessionPool</span> ressemble à... +<pre> +<strong>class SessionPool { + function SessionPool() { + ... + } + + function &findSession($cookie) { + ... + } + ... +} + +class Session { + ... +}</strong> + +</pre> + Alors que pour notre code de log, nous avons... +<pre> +<strong> +class Log { + function Log() { + ... + } + + function message() { + ... + } +} + +class LoggingSessionPool { + function LoggingSessionPool(&$session_pool, &$log) { + ... + } + + function &findSession(\$cookie) { + ... + } + ... +}</strong> +</pre> + Dans tout ceci, la seule classe à tester est <span class="new_code">LoggingSessionPool</span>. En particulier, nous voulons vérifier que la méthode <span class="new_code">findSession()</span> est appelée avec le bon identifiant de session au sein du cookie et qu'elle renvoie bien le message "Starting session $cookie" au loggueur. + </p> + <p> + Bien que nous ne testions que quelques lignes de code de production, voici la liste des choses à faire dans un scénario de test conventionnel : + <ol> + <li>Créer un objet de log.</li> + <li>Indiquer le répertoire d'écriture du fichier de log.</li> + <li>Modifier les droits sur le répertoire pour pouvoir y écrire le fichier.</li> + <li>Créer un objet <span class="new_code">SessionPool</span>.</li> + <li>Lancer une session, ce qui demande probablement pas mal de choses.</li> + <li>Invoquer <span class="new_code">findSession()</span>.</li> + <li>Lire le nouvel identifiant de sessions (en espérant qu'il existe un accesseur !).</li> + <li>Lever une assertion de test pour vérifier que cet identifiant correspond bien au cookie.</li> + <li>Lire la dernière ligne du fichier de log.</li> + <li>Supprimer avec une (ou plusieurs) expression rationnelle les timestamps de log en trop, etc.</li> + <li>Vérifier que le message de session est bien dans le texte.</li> + </ol> + Pas étonnant que les développeurs détestent écrire des tests quand ils sont aussi ingrats. Pour rendre les choses encore pire, à chaque fois que le format de log change ou bien que la méthode de création des sessions change, nous devons réécrire une partie des tests alors même qu'ils ne testent pas ces parties du système. Nous sommes en train de préparer le cauchemar pour les développeurs de ces autres classes. + </p> + <p> + A la place, voici la méthode complète pour le test avec un peu de magie via les objets fantaisie... +<pre> +Mock::generate('Session'); +Mock::generate('SessionPool'); +Mock::generate('Log'); + +class LoggingSessionPoolTest extends UnitTestCase { + ... + function testFindSessionLogging() {<strong> + $session = &new MockSession($this); + $pool = &new MockSessionPool($this); + $pool->setReturnReference('findSession', $session); + $pool->expectOnce('findSession', array('abc')); + + $log = &new MockLog($this); + $log->expectOnce('message', array('Starting session abc')); + + $logging_pool = &new LoggingSessionPool($pool, $log); + $this->assertReference($logging_pool->findSession('abc'), $session); + $pool->tally(); + $log->tally();</strong> + } +} +</pre> + Commençons par écrire une session simulacre. Pas la peine d'être trop pointilleux avec celle-ci puisque la vérification de la session désirée est effectuée ailleurs. Nous avons juste besoin de vérifier qu'il s'agit de la même que celle qui vient du groupe commun des sessions. + </p> + <p> + <span class="new_code">findSession()</span> est un méthode fabrique dont la simulation est décrite <a href="#stub">plus haut</a>. Le point de départ vient avec le premier appel <span class="new_code">expectOnce()</span>. Cette ligne indique qu'à chaque fois que <span class="new_code">findSession()</span> est invoqué sur l'objet fantaisie, il vérifiera les arguments entrant. S'il ne reçoit que la chaîne "abc" en tant qu'argument alors un succès est envoyé au testeur unitaire, sinon c'est un échec qui est généré. Il s'agit là de la partie qui teste si nous avons bien la bonne session. La liste des arguments suit une format identique à celui qui précise les valeurs renvoyées. Vous pouvez avoir des jokers et des séquences et l'ordre de l'évaluation restera le même. + </p> + <p> + Si l'appel n'est jamais effectué alors n'est généré ni le succès, ni l'échec. Pour contourner cette limitation, nous devons dire à l'objet fantaisie que le test est terminé : il pourra alors décider si les attentes ont été répondues. L'assertion du testeur unitaire de ceci est déclenchée par l'appel <span class="new_code">tally()</span> à la fin du test. + </p> + <p> + Nous utilisons le même modèle pour mettre sur pied le loggueur fantaisie. Nous lui indiquons que <span class="new_code">message()</span> devrait être invoqué une fois et une fois seulement avec l'argument "Starting session abc". En testant les arguments d'appel, plutôt que ceux de sorite du loggueur, nous isolons le test de tout modification dans le loggueur. + </p> + <p> + Nous commençons le lancement nos tests à la création du nouveau <span class="new_code">LoggingSessionPool</span> et nous l'alimentons avec nos objets fantaisie juste créés. Désormais tout est sous contrôle. Au final nous confirmons que le <span class="new_code">$session</span> donné au décorateur est bien celui reçu et prions les objets fantaisie de lancer leurs tests de comptage d'appel interne avec les appels <span class="new_code">tally()</span>. + </p> + <p> + Il y a encore pas mal de code de test, mais ce code est très strict. S'il vous semble encore terrifiant il l'est bien moins que si nous avions essayé sans les objets fantaisie et ce test en particulier, interactions plutôt que résultat, est toujours plus difficile à mettre en place. Le plus souvent vous aurez besoin de tester des situations plus complexes sans ce niveau ni cette précision. En outre une partie peut être remaniée avec la méthode de scénario de test <span class="new_code">setUp()</span>. + </p> + <p> + Voici la liste complète des attentes que vous pouvez placer sur un objet fantaisie avec <a href="http://www.lastcraft.com/simple_test.php">SimpleTest</a>... + <table> +<thead> + <tr> +<th>Attente</th><th>Nécessite <span class="new_code">tally()</span></th> +</tr> + </thead> +<tbody> +<tr> + <td><span class="new_code">expectArguments($method, $args)</span></td> + <td style="text-align: center">Non</td> + </tr> + <tr> + <td><span class="new_code">expectArgumentsAt($timing, $method, $args)</span></td> + <td style="text-align: center">Non</td> + </tr> + <tr> + <td><span class="new_code">expectCallCount($method, $count)</span></td> + <td style="text-align: center">Oui</td> + </tr> + <tr> + <td><span class="new_code">expectMaximumCallCount($method, $count)</span></td> + <td style="text-align: center">Non</td> + </tr> + <tr> + <td><span class="new_code">expectMinimumCallCount($method, $count)</span></td> + <td style="text-align: center">Oui</td> + </tr> + <tr> + <td><span class="new_code">expectNever($method)</span></td> + <td style="text-align: center">Non</td> + </tr> + <tr> + <td><span class="new_code">expectOnce($method, $args)</span></td> + <td style="text-align: center">Oui</td> + </tr> + <tr> + <td><span class="new_code">expectAtLeastOnce($method, $args)</span></td> + <td style="text-align: center">Oui</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, à laquelle la condition doit être appliquée.</dd> + <dt class="new_code">$args</dt> + <dd> + Les arguments sous la forme d'une liste. Les jokers peuvent être inclus de la même manière qu'avec <span class="new_code">setReturn()</span>. Cet argument est optionel pour <span class="new_code">expectOnce()</span> et <span class="new_code">expectAtLeastOnce()</span>. + </dd> + <dt class="new_code">$timing</dt> + <dd> + Le seul point dans le temps pour tester la condition. Le premier appel commence à zéro. + </dd> + <dt class="new_code">$count</dt> + <dd>Le nombre d'appels attendu.</dd> + </dl> + La méthode <span class="new_code">expectMaximumCallCount()</span> est légèrement différente dans le sens où elle ne pourra générer qu'un échec. Elle reste silencieuse si la limite n'est jamais atteinte. + </p> + <p> + Comme avec les assertions dans les scénarios de test, toutes ces attentes peuvent accepter une surcharge de message sous la forme d'un paramètre supplémentaire. Par ailleurs le message d'échec original peut être inclus dans le résultat avec "%s". + </p> + + <p> +<a class="target" name="approches"> +<h2>D'autres approches</h2> +</a> +</p> + <p> + Il existe trois approches pour créer des objets fantaisie en comprenant celle utiliser par SimpleTest. Les coder à la main en utilisant une classe de base, les générer dans un fichier ou les générer dynamiquement à la volée. + </p> + <p> + Les objets fantaisie générés avec <a href="simple_test.html">SimpleTest</a> sont dynamiques. Ils sont créés à l'exécution dans la mémoire, grâce à <span class="new_code">eval()</span>, plutôt qu'écrit dans un fichier. Cette opération les rend facile à créer, en une seule ligne, surtout par rapport à leur création à la main dans une hiérarchie de classe parallèle. Le problème avec ce comportement tient généralement dans la mise en place des tests proprement dits. Si les objets originaux changent les versions fantaisie sur lesquels reposent les tests, une désynchronisation peut subvenir. Cela peut aussi arriver avec l'approche en hiérarchie parallèle, mais c'est détecté beaucoup plus vite. + </p> + <p> + Bien sûr, la solution est d'ajouter de véritables tests d'intégration. Vous n'en avez pas besoin de beaucoup et le côté pratique des objets fantaisie fait plus que compenser la petite dose de test supplémentaire. Vous ne pouvez pas avoir confiance dans du code qui ne serait testé que par des objets fantaisie. + </p> + <p> + Si vous restez déterminé de construire des librairies statiques d'objets fantaisie parce que vous souhaitez émuler un comportement très spécifique, vous pouvez y parvenir grâce au générateur de classe de SimpleTest. Dans votre fichier librairie, par exemple <em>mocks/connection.php</em> pour une connexion à une base de données, créer un objet fantaisie et provoquer m'héritage pour hériter pour surcharger des méthodes spéciales ou ajouter des préréglages... +<pre> +<?php + require_once('simpletest/mock_objects.php'); + require_once('../classes/connection.php'); +<strong> + Mock::generate('Connection', 'BasicMockConnection'); + class MockConnection extends BasicMockConnection { + function MockConnection(&$test, $wildcard = '*') { + $this->BasicMockConnection($test, $wildcard); + $this->setReturn('query', false); + } + }</strong> +?> +</pre> + L'appel <span class="new_code">generate</span> dit au générateur de classe d'en créer une appelée <span class="new_code">BasicMockConnection</span> plutôt que la plus courante <span class="new_code">MockConnection</span>. Ensuite nous héritons à partir de celle-ci pour obtenir notre version de <span class="new_code">MockConnection</span>. En interceptant de cette manière nous pouvons ajouter un comportement, ici transformer la valeur par défaut de <span class="new_code">query()</span> en "false". + En utilisant le nom par défaut nous garantissons que le générateur de classe fantaisie n'en recréera pas une autre différente si il est invoqué ailleurs dans les tests. Il ne créera jamais de classe si elle existe déjà. Aussi longtemps que le fichier ci-dessus est inclus avant alors tous les tests qui généraient <span class="new_code">MockConnection</span> devraient utiliser notre version à présent. Par contre si nous avons une erreur dans l'ordre et que la librairie de fantaisie en crée une d'abord alors la création de la classe échouera tout simplement. + </p> + <p> + Utiliser cette astuce si vous vous trouvez avec beaucoup de comportement en commun sur les objets fantaisie ou si vous avez de fréquents problèmes d'intégration plus tard dans les étapes de test. + </p> + + <p> +<a class="target" name="autres_testeurs"> +<h2>Je pense que SimpleTest pue !</h2> +</a> +</p> + <p> + Mais au moment d'écrire ces lignes c'est le seul à gérer les objets fantaisie, donc vous êtes bloqué avec lui ? + </p> + <p> + Non, pas du tout. + <a href="simple_test.html">SimpleTest</a> est une boîte à outils et parmi ceux-ci on trouve les objets fantaisie qui peuvent être utilisés indépendamment. Supposons que vous avez votre propre testeur unitaire favori et que tous vos tests actuels l'utilisent. Prétendez que vous avez appelé votre tester unitaire PHPUnit (c'est ce que tout le monde a fait) et que la classe principale de test ressemble à... +<pre> +class PHPUnit { + function PHPUnit() { + } + + function assertion($message, $assertion) { + } + ... +} +</pre> + La seule chose que la méthode <span class="new_code">assertion()</span> réalise, c'est de préparer une sortie embellie alors le paramètre boolien de l'assertion sert à déterminer s'il s'agit d'une erreur ou d'un succès. Supposons qu'elle est utilisée de la manière suivante... +<pre> +$unit_test = new PHPUnit(); +$unit_test>assertion('I hope this file exists', file_exists('my_file')); +</pre> + Comment utiliser les objets fantaisie avec ceci ? + </p> + <p> + Il y a une méthode protégée sur la classe de base des objets fantaisie : elle s'appelle <span class="new_code">_assertTrue()</span>. En surchargeant cette méthode nous pouvons utiliser notre propre format d'assertion. Nous commençons avec une sous-classe, dans <em>my_mock.php</em>... +<pre> +<strong><?php + require_once('simpletest/mock_objects.php'); + + class MyMock extends SimpleMock() { + function MyMock(&$test, $wildcard) { + $this->SimpleMock($test, $wildcard); + } + + function _assertTrue($assertion, $message) { + $test = &$this->getTest(); + $test->assertion($message, $assertion); + } + } +?></strong> +</pre> + Maintenant une instance de <span class="new_code">MyMock</span> créera un objet qui parle le même langage que votre testeur. Bien sûr le truc c'est que nous créons jamais un tel objet : le générateur s'en chargera. Nous avons juste besoin d'une ligne de code supplémentaire pour dire au générateur d'utiliser vos nouveaux objets fantaisie... +<pre> +<?php + require_once('simpletst/mock_objects.php'); + + class MyMock extends SimpleMock() { + function MyMock($test, $wildcard) { + $this->SimpleMock(&$test, $wildcard); + } + + function _assertTrue($assertion, $message , &$test) { + $test->assertion($message, $assertion); + } + }<strong> + SimpleTestOptions::setMockBaseClass('MyMock');</strong> +?> +</pre> + A partir de maintenant vous avez juste à inclure <em>my_mock.php</em> à la place de la version par défaut <em>simple_mock.php</em> et vous pouvez introduire des objets fantaisie dans votre suite de tests existants. + </p> + + </div> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/overview.html b/tests/test_tools/simpletest/docs/fr/overview.html new file mode 100755 index 00000000..b6965753 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/overview.html @@ -0,0 +1,294 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Apercu de SimpleTest</h1> +<div class="content"> + <p> +<a class="target" name="resume"> +<h2>Qu'est-ce que SimpleTest ?</h2> +</a> +</p> + <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> + + <p> +<a class="target" name="fonctionnalites"> +<h2>Liste des fonctionnalites</h2> +</a> +</p> + <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 test 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>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> + <tr> + <td>Test de l'upload de fichier</td> + <td>Peut simuler la balise input de type file</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> + + <p> +<a class="target" name="ressources"> +<h2>Ressources sur le web pour les tests</h2> +</a> +</p> + <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/wiki/MocksObjectsPaper">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> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/partial_mocks_documentation.html b/tests/test_tools/simpletest/docs/fr/partial_mocks_documentation.html new file mode 100755 index 00000000..4098ab45 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/partial_mocks_documentation.html @@ -0,0 +1,333 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur les objets fantaisie partiels</h1> +<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> + + <p> +<a class="target" name="injection"> +<h2>Le problème de l'injection dans un objet fantaisie</h2> +</a> +</p> + <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($this); + ... + $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($this); + ... + $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($this); + ... + $network = &new MockNetwork($this); + $network->setReturnReference('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> + Peut-on trouver un juste milieu ? + </p> + + <p> +<a class="target" name="creation"> +<h2>Méthode fabrique protégée</h2> +</a> +</p> + <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> + + function &_createSocket($ip, $port) { + return new Socket($ip, $port); + }</strong> + } +?> +</pre> + 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(); + } + + 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($this); + ... + $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> + + <p> +<a class="target" name="partiel"> +<h2>Un objet fantaisie partiel</h2> +</a> +</p> + <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($this); + ... + $telnet = &new TelnetTestVersion($this); + $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($this); + ... + $telnet = &new TelnetTestVersion($this); + $telnet->setReturnReference('_createSocket', $socket);<strong> + $telnet->expectOnce('_createSocket', array('127.0.0.1', 21));</strong> + $telnet->Telnet(); + $telnet->connect('127.0.0.1', 21, 'Me', 'Secret'); + ...<strong> + $telnet->tally();</strong> + } +} +</pre> + </p> + + <p> +<a class="target" name="moins"> +<h2>Tester moins qu'une classe</h2> +</a> +</p> + <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éthode à part celle que nous voulons effectivement tester. + </p> + <p> + Cette situation est assez hypothétique, étant donné que je ne l'ai jamais essayée. Je suis ouvert à cette possibilité, mais 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> + Pour choisir le mécanisme à utiliser, on en revient toujours aux standards de code de votre projet. + </p> + + </div> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/reporter_documentation.html b/tests/test_tools/simpletest/docs/fr/reporter_documentation.html new file mode 100755 index 00000000..4f927781 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/reporter_documentation.html @@ -0,0 +1,386 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur le rapporteur de test</h1> +<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> + + <p> +<a class="target" name="html"> +<h2>Les résultats rapportés au format HTML</h2> +</a> +</p> + <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 HtmlReporter($encoding) { ... } + public makeDry(boolean $is_dry) { ... } + public void paintHeader(string $test_name) { ... } + public void sendNoCacheHeaders() { ... } + public void paintFooter(string $test_name) { ... } + public void paintGroupStart(string $test_name, integer $size) { ... } + public void paintGroupEnd(string $test_name) { ... } + public void paintCaseStart(string $test_name) { ... } + public void paintCaseEnd(string $test_name) { ... } + public void paintMethodStart(string $test_name) { ... } + public void paintMethodEnd(string $test_name) { ... } + public void paintFail(string $message) { ... } + public void paintPass(string $message) { ... } + public void paintError(string $message) { ... } + public void paintException(string $message) { ... } + public void paintMessage(string $message) { ... } + public void paintFormattedMessage(string $message) { ... } + protected string _getCss() { ... } + public array getTestList() { ... } + public integer getPassCount() { ... } + public integer getFailCount() { ... } + public integer getExceptionCount() { ... } + public integer getTestCaseCount() { ... } + public integer getTestCaseProgress() { ... } +} +</pre> + 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 test du niveau le plus haut et donc c'est de là que le <span class="new_code">$test_name</span> arrive. Il peint les titres 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 test 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éfait 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 le plus proche du coeur -- 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 ShowPasses extends HtmlReporter { + + function paintPass($message) { + parent::paintPass($message); + print "&<span class=\"pass\">Pass</span>: "; + $breadcrumb = $this->getTestList(); + array_shift($breadcrumb); + print implode("-&gt;", $breadcrumb); + print "-&gt;$message<br />\n"; + } + + function _getCss() { + return parent::_getCss() . ' .pass { color: green; }'; + } +}</strong> +</pre> + </p> + <p> + 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, par exemple, l'affichage un 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> + + <p> +<a class="target" name="autre"> +<h2>Etendre le rapporteur</h2> +</a> +</p> + <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 canvas vierge pour votre propre création, serait... +<pre> +<strong>require_once('simpletest/simple_test.php');</strong> + +class MyDisplay extends SimpleReporter {<strong> + </strong> + function paintHeader($test_name) { + } + + function paintFooter($test_name) { + } + + function paintStart($test_name, $size) {<strong> + parent::paintStart($test_name, $size);</strong> + } + + function paintEnd($test_name, $size) {<strong> + parent::paintEnd($test_name, $size);</strong> + } + + function paintPass($message) {<strong> + parent::paintPass($message);</strong> + } + + function paintFail($message) {<strong> + parent::paintFail($message);</strong> + } +} +</pre> + Aucune sortie ne viendrait de cette classe jusqu'à un ajout de votre part. + </p> + + <p> +<a class="target" name="cli"> +<h2>Le rapporteur en ligne de commande</h2> +</a> +</p> + <p> + SimpleTest est aussi livré avec un rapporteur en ligne de commande, minime lui aussi. L'interface imite celle de JUnit, sauf qu'elle envoie les messages d'erreur au fur et à mesure de leur arrivée. Pour utiliser le rapporteur en ligne de commande, il suffit de l'intervertir avec celui de la version HTML... +<pre> +<?php + require_once('simpletest/unit_tester.php'); + require_once('simpletest/reporter.php'); + + $test = &new GroupTest('File test'); + $test->addTestFile('tests/file_test.php'); + $test->run(<strong>new TextReporter()</strong>); +?> +</pre> + 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, 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, 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/unit_tester.php'); + require_once('simpletest/reporter.php'); + + $test = &new GroupTest('File test'); + $test->addTestFile('tests/file_test.php'); + <strong>exit ($test->run(new TextReporter()) ? 0 : 1);</strong> +?> +</pre> + Bien sûr l'objectif n'est 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/unit_tester.php'); + require_once('simpletest/reporter.php'); + + $test = &new GroupTest('File test'); + $test->addTestFile('tests/file_test.php'); + <strong>if (TextReporter::inCli()) {</strong> + exit ($test->run(new TextReporter()) ? 0 : 1); + <strong>}</strong> + $test->run(new HtmlReporter()); +?> +</pre> + Il s'agit là de la forme utilisée par SimpleTest lui-même. + </p> + + <p> +<a class="target" name="xml"> +<h2>Test distant</h2> +</a> +</p> + <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> + 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> + Un problème des suites de test très grandes, c'est qu'elles peuvent venir à bout de la limite de mémoire par défaut d'un process PHP - 8Mb. 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 parser à nouveau pour agrégrer 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('../reporter.php'); + + $test_url = ...; + $dry_url = ...; + + $test = &new GroupTest('Remote tests'); + $test->addTestCase(<strong>new RemoteTestCase($test_url, $dry_url)</strong>); + $test->run(new HtmlReporter()); +?> +</pre> + <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 quel autre groupe de test. + </p> + + </div> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/server_stubs_documentation.html b/tests/test_tools/simpletest/docs/fr/server_stubs_documentation.html new file mode 100755 index 00000000..59085795 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/server_stubs_documentation.html @@ -0,0 +1,279 @@ +<html> +<head> +<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documentation SimpleTest : les bouchons serveur</title> +<link rel="stylesheet" type="text/css" href="docs.css" title="Styles"> +</head> +<body> +<div class="menu_back"> +<div class="menu"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur les bouchons serveur</h1> +<div class="content"> + <p> +<a class="target" name="quoi"> +<h2>Que sont les bouchons serveur ?</h2> +</a> +</p> + <p> + Au départ il s'agit d'un modèle de conception initié par Robert Binder (Testing object-oriented systems: models, patterns, and tools, Addison-Wesley) in 1999. Un bouchon serveur est une simulation d'un objet ou d'un composant. Il doit remplacer exactement un composant dans un système pour des raisons de testabilité ou de prototypage, tout en restant léger. Il permet aux tests de tourner plus rapidement ou alors, si la classe simulée n'a pas été écrite, juste de fonctionner. + </p> + + <p> +<a class="target" name="creation"> +<h2>Créer des bouchons serveur</h2> +</a> +</p> + <p> + Nous avons juste besoin d'une classe préexistante, par exemple une connexion vers une base de données qui ressemblerait à... +<pre> +<strong>class DatabaseConnection { + function DatabaseConnection() { + } + + function query() { + } + + function selectQuery() { + } +}</strong> +</pre> + La classe n'a même pas encore besoin d'avoir été implémentée. Pour créer la version bouchonnée de cette classe, nous incluons la librairie de bouchon serveur et exécutons le générateur... +<pre> +<strong>require_once('simpletest/mock_objects.php'); +require_once('database_connection.php'); +Stub::generate('DatabaseConnection');</strong> +</pre> + Est généré un clone de la classe appelé <span class="new_code">StubDatabaseConnection</span>. Nous pouvons alors créer des instances de cette nouvelle classe à l'intérieur de notre prototype de script... +<pre> +require_once('simpletest/mock_objects.php'); +require_once('database_connection.php'); +Stub::generate('DatabaseConnection'); +<strong> +$connection = new StubDatabaseConnection(); +</strong> +</pre> + La version bouchonnée de la classe contient toutes les méthodes de l'original de telle sorte qu'une opération comme <span class="new_code">$connection->query()</span> soit encore légale. La valeur retournée sera <span class="new_code">null</span>, Mais nous pouvons y remédier avec... +<pre> +<strong>$connection->setReturnValue('query', 37)</strong> +</pre> + Désormais à chaque appel de <span class="new_code">$connection->query()</span> nous obtenons un résultat de 37. Nous pouvons choisir n'importe quelle valeur pour le résultat, par exemple un hash de résultats provenant d'un base de données imaginaire ou alors une liste d'objets persistants. Peu importe les paramètres, nous obtenons systématiquement les même valeurs chaque fois qu'ils ont été initialisés de la sorte : ça ne ressemble peut-être pas à une réponse convaincante venant d'une connexion vers une base de données. Mais pour la demi-douzaine de lignes d'une méthode de test c'est souvent largement suffisant. + </p> + + <p> +<a class="target" name="mod%C3%A8les"> +<h2>Modèles de simulation</h2> +</a> +</p> + <p> + Sauf que les choses ne sont que rarement aussi simples. Parmi les problèmes les plus courants on trouve les itérateurs : le renvoi d'une valeur constante peut causer une boucle infini dans l'objet testé. Pour ceux-ci nous avons besoin de mettre sur pied une suite de valeurs. Prenons par exemple un itérateur simple qui ressemble à... +<pre> +class Iterator { + function Iterator() { + } + + function next() { + } +} +</pre> + C'est probablement le plus simple des itérateurs possibles. Supposons que cet itérateur ne retourne que du texte, jusqu'à la fin - quand il retourne <span class="new_code">false</span>. Une simulation est possible avec... +<pre> +<strong>Stub::generate('Iterator'); + +$iterator = new StubIterator(); +$iterator->setReturnValue('next', false); +$iterator->setReturnValueAt(0, 'next', 'First string'); +$iterator->setReturnValueAt(1, 'next', 'Second string');</strong> +</pre> + A l'appel de <span class="new_code">next()</span> sur l'itérateur bouchonné il va d'abord renvoyer "First string", puis au second appel c'est "Second string" qui sera renvoyé. Finalement pour tous les autres appels, il s'agira d'un <span class="new_code">false</span>. Les valeurs renvoyées successivement ont priorité sur la valeur constante renvoyé. Cette dernière est un genre de valeur par défaut. + </p> + <p> + Une autre situation délicate est une opération <span class="new_code">get()</span> surchargée. Un exemple ? Un porteur d'information avec des pairs de clef / valeur. Prenons une classe de configuration... +<pre> +class Configuration { + function Configuration() { + } + + function getValue($key) { + } +} +</pre> + Il s'agit d'une situation propice à l'utilisation d'objets bouchon, surtout que la configuration en production dépend invariablement de la machine : l'utiliser directement ne va pas nous aider à maintenir notre confiance dans nos tests. Sauf que le problème tient de ce que toutes les données proviennent de la méthode <span class="new_code">getValue()</span> et que nous voulons des résultats différents suivant la clef. Par chance les bouchons ont un système de filtre... +<pre> +<strong>Stub::generate('Configuration'); + +$config = &new StubConfiguration(); +$config->setReturnValue('getValue', 'primary', array('db_host')); +$config->setReturnValue('getValue', 'admin', array('db_user')); +$config->setReturnValue('getValue', 'secret', array('db_password'));</strong> +</pre> + Ce paramètre supplémentaire est une liste d'arguments que l'on peut utiliser. Dans ce cas nous essayons d'utiliser un unique argument, à savoir la clef recherchée. Maintenant quand on invoque le bouchon serveur via la méthode <span class="new_code">getValue()</span> avec... +<pre> +$config->getValue('db_user'); +</pre> + ...il renvoie "admin". Il le trouve en essayant d'assortir successivement les arguments d'entrée avec sa liste de ceux de sortie jusqu'au moment où une correspondance exacte est trouvée. + </p> + <p> + Vous pouvez définir un argument par défaut avec... +<pre> +<strong> +$config->setReturnValue('getValue', false, array('*'));</strong> +</pre> + Attention ce n'est pas équivalent à initialiser la valeur retournée sans aucun argument. +<pre> +<strong> +$config->setReturnValue('getValue', false);</strong> +</pre> + Dans le premier cas il acceptera n'importe quel argument, mais exactement un -- pas plus -- est nécessaire. Dans le second cas n'importe quel nombre d'arguments fera l'affaire : il agit comme un <cite>catchall</cite> après tous les correspondances. Prenez garde à l'ordre : si nous ajoutons un autre paramètre après le joker ('*') il sera ignoré puisque le joker aura été trouvé auparavant. Avec des listes de paramètres complexes l'ordre peut devenir crucial, au risque de perdre des correspondances souhaitées, masquées par un joker antérieur. Pensez à mettre d'abord les cas les plus spécifiques si vous n'êtes pas sûr. + </p> + <p> + Il y a des fois où l'on souhaite qu'un objet spécifique soit servi par le bouchon plutôt qu'une simple copie. La sémantique de la copie en PHP nous force à utiliser une autre méthode pour cela. Vous êtes peut-être en train de simuler un conteneur par exemple... +<pre> +class Thing { +} + +class Vector { + function Vector() { + } + + function get($index) { + } +} +</pre> + Dans ce cas vous pouvez mettre une référence dans la liste renvoyée par le bouchon... +<pre> +Stub::generate('Vector'); + +$thing = new Thing();<strong> +$vector = &new StubVector(); +$vector->setReturnReference('get', $thing, array(12));</strong> +</pre> + Avec ce petit arrangement vous vous assurez qu'à chaque fois que <span class="new_code">$vector->get(12)</span> est appelé il renverra le même <span class="new_code">$thing</span>. + </p> + <p> + Ces trois facteurs, ordre, paramètres et copie (ou référence), peuvent être combinés orthogonalement. Par exemple... +<pre> +$complex = &new StubComplexThing(); +$stuff = new Stuff();<strong> +$complex->setReturnReferenceAt(3, 'get', $stuff, array('*', 1));</strong> +</pre> + Le <span class="new_code">$stuff</span> ne sera renvoyé qu'au troisième appel et seulement si deux paramètres étaient indiqués, avec la contrainte que le second de ceux-ci soit l'entier 1. N'est-ce pas suffisant pour des situations de prototypage simple ? + </p> + <p> + Un dernier cas critique reste celle d'un objet en créant un autre, connu sous le nom du modèle factory - fabrique. Supposons qu'après une requête réussie à notre base de données imaginaire, un ensemble de résultats est retourné sous la forme d'un itérateur, chaque appel à <span class="new_code">next()</span> donnant un ligne et à la fin un <span class="new_code">false</span>. + Au premier abord, ça donne l'impression d'être cauchemardesque à simuler. Alors qu'en fait tout peut être bouchonné en utilisant les mécanismes ci-dessus. + </p> + <p> + Voici comment... +<pre> +Stub::generate('DatabaseConnection'); +Stub::generate('ResultIterator'); + +class DatabaseTest extends UnitTestCase { + + function testUserFinder() {<strong> + $result = &new StubResultIterator(); + $result->setReturnValue('next', false); + $result->setReturnValueAt(0, 'next', array(1, 'tom')); + $result->setReturnValueAt(1, 'next', array(3, 'dick')); + $result->setReturnValueAt(2, 'next', array(6, 'harry')); + + $connection = &new StubDatabaseConnection(); + $connection->setReturnValue('query', false); + $connection->setReturnReference( + 'query', + $result, + array('select id, name from users'));</strong> + + $finder = &new UserFinder($connection); + $this->assertIdentical( + $finder->findNames(), + array('tom', 'dick', 'harry')); + } +} +</pre> + Désormais ce n'est que si notre <span class="new_code">$connection</span> est appelé avec la bonne <span class="new_code">query()</span> que le <span class="new_code">$result</span> sera renvoyé après le troisième appel à <span class="new_code">next()</span>. Cela devrait être suffisant pour que notre classe <span class="new_code">UserFinder</span>, la classe effectivement testée à ce niveau, puisse s'exécuter comme il faut. Un test très précis et pas une seule base de données à l'horizon. + </p> + + <p> +<a class="target" name="options"> +<h2>Options de création pour les bouchons</h2> +</a> +</p> + <p> + Il y a d'autres options additionnelles à la création d'un bouchon. Au moment de la génération nous pouvons changer le nom de la classe... +<pre> +<strong>Stub::generate('Iterator', 'MyStubIterator'); +$iterator = &new MyStubIterator(); +</strong> +</pre> + Pris tout seul ce n'est pas très utile étant donné qu'il n'y aurait pas de différence entre cette classe et celle par défaut -- à part le nom bien entendu. Par contre nous pouvons aussi lui ajouter d'autres méthodes qui ne se trouveraient pas dans l'interface originale... +<pre> +class Iterator { +} +<strong>Stub::generate('Iterator', 'PrototypeIterator', array('next', 'isError')); +$iterator = &new PrototypeIterator(); +$iterator->setReturnValue('next', 0); +</strong> +</pre> + Les méthodes <span class="new_code">next()</span> et <span class="new_code">isError()</span> peuvent maintenant renvoyer des ensembles de valeurs exactement comme si elles existaient dans la classe originale. + </p> + <p> + Un moyen encore plus ésotérique de modifier les bouchons est de changer le joker utiliser par défaut pour la correspondance des paramètres. +<pre> +<strong>Stub::generate('Connection'); +$iterator = &new StubConnection('wild'); +$iterator->setReturnValue('query', array('id' => 33), array('wild')); +</strong> +</pre> + L'unique raison valable pour effectuer cette opération, c'est quand vous souhaitez tester la chaîne "*" sans pour autant l'interpréter comme un "n'importe lequel". + </p> + + </div> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/unit_test_documentation.html b/tests/test_tools/simpletest/docs/fr/unit_test_documentation.html new file mode 100755 index 00000000..3dcfeca5 --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/unit_test_documentation.html @@ -0,0 +1,306 @@ +<html> +<head> +<META http-equiv="Content-Type" content="text/html; charset=UTF-8"> +<title>Documenation 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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur les tests unitaires en PHP</h1> +<div class="content"> + <p> +<a class="target" name="unitaire"> +<h2>Scénarios de tests unitaires</h2> +</a> +</p> + <p> + Le coeur du système est un framework de test 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('../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">assertWantedPattern($p, $x)</span></td><td>Echoue sauf si l'expression rationnelle $p capture $x</td> +</tr> + <tr> +<td><span class="new_code">assertNoUnwantedPattern($p, $x)</span></td><td>Echoue si l'expression rationnelle $p capture $x</td> +</tr> + <tr> +<td><span class="new_code">assertNoErrors()</span></td><td>Echoue si une erreur PHP arrive</td> +</tr> + <tr> +<td><span class="new_code">assertError($x)</span></td><td>Echoue si aucune erreur ou message incorrect de PHP n'arrive</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->assertWantedPattern('/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>trigger_error('Disaster'); +trigger_error('Catastrophe'); +$this->assertError(); +$this->assertError('Catastrophe'); +$this->assertNoErrors();</strong> +</pre> + Ici, il y a besoin d'une petite explication : toutes passent ! + </p> + <p> + Les erreurs PHP dans SimpleTest sont piégées et placées dans une queue. Ici la première vérification d'erreur attrape le message "Disaster" sans vérifier le texte et passe. Résultat : l'erreur est supprimée de la queue. La vérification suivante teste non seulement l'existence de l'erreur mais aussi le texte qui correspond : un autre succès. Désormais la queue est vide et le dernier test passe aussi. Si une autre erreur non vérifiée est encore dans la queue à la fin de notre méthode de test alors une exception sera rapportée dans le test. Notez que SimpleTest ne peut pas attraper les erreurs PHP à la compilation. + </p> + <p> + Les scénarios de test 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">sendMessage()</span></td><td>Envoie un message d'état aux systèmes d'affichage qui le supporte</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> + <tr> +<td><span class="new_code">swallowErrors()</span></td><td>Vide les erreurs de la queue</td> +</tr> + </tbody> +</table> + </p> + + <p> +<a class="target" name="extension_unitaire"> +<h2>Etendre les scénarios de test</h2> +</a> +</p> + <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/unit_tester.php'); +<strong> +class FileTester extends UnitTestCase { + function FileTester($name = false) { + $this->UnitTestCase($name); + } + + function assertFileExists($filename, $message = '%s') { + $this->assertTrue( + file_exists($filename), + sprintf($message, 'File [$filename] existence check')); + }</strong> +} +</pre> + 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> + 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> + + <p> +<a class="target" name="lancement_unitaire"> +<h2>Lancer un unique scénario de test</h2> +</a> +</p> + <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. Voici l'échafaudage nécessaire pour lancer un scénario de test solitaire... +<pre> +<?php + require_once('simpletest/unit_tester.php');<strong> + require_once('simpletest/reporter.php');</strong> + require_once('../classes/writer.php'); + + class FileTestCase extends UnitTestCase { + function FileTestCase() { + $this->UnitTestCase('File test'); + } + }<strong> + + $test = &new FileTestCase(); + $test->run(new HtmlReporter());</strong> +?> +</pre> + 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> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> diff --git a/tests/test_tools/simpletest/docs/fr/web_tester_documentation.html b/tests/test_tools/simpletest/docs/fr/web_tester_documentation.html new file mode 100755 index 00000000..86044e5e --- /dev/null +++ b/tests/test_tools/simpletest/docs/fr/web_tester_documentation.html @@ -0,0 +1,397 @@ +<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"> +<h2> +<a href="index.html">SimpleTest</a> +</h2> +<ul> +<li> +<a href="overview.html">Overview</a> +</li> +<li> +<a href="unit_test_documentation.html">Unit tester</a> +</li> +<li> +<a href="group_test_documentation.html">Group tests</a> +</li> +<li> +<a href="server_stubs_documentation.html">Server stubs</a> +</li> +<li> +<a href="mock_objects_documentation.html">Mock objects</a> +</li> +<li> +<a href="partial_mocks_documentation.html">Partial mocks</a> +</li> +<li> +<a href="reporter_documentation.html">Reporting</a> +</li> +<li> +<a href="expectation_documentation.html">Expectations</a> +</li> +<li> +<a href="web_tester_documentation.html">Web tester</a> +</li> +<li> +<a href="form_testing_documentation.html">Testing forms</a> +</li> +<li> +<a href="authentication_documentation.html">Authentication</a> +</li> +<li> +<a href="browser_documentation.html">Scriptable browser</a> +</li> +</ul> +</div> +</div> +<h1>Documentation sur le testeur web</h1> +<div class="content"> + <p> +<a class="target" name="telecharger"> +<h2>Télécharger une page</h2> +</a> +</p> + <p> + Tester des classes c'es 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<strong> + require_once('simpletest/web_tester.php');</strong> + require_once('simpletest/reporter.php'); + + $test = &new GroupTest('Web site tests');<strong> + $test->addTestFile('lastcraft_test.php');</strong> + exit ($test->run(new TextReporter()) ? 0 : 1); +?> +</pre> + 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> + + <p> +<a class="target" name="contenu"> +<h2>Tester le contenu d'une page</h2> +</a> +</p> + <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> + + <p> +<a class="target" name="navigation"> +<h2>Navigeur dans un site web</h2> +</a> +</p> + <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 avec ce titre ou ce texte dans l'attribut alt</td> +</tr> + <tr> +<td><span class="new_code">clickImageByName($name, $x, $y)</span></td><td>Clique sur une balise input de type image avec ce nom</td> +</tr> + <tr> +<td><span class="new_code">clickImageById($id, $x, $y)</span></td><td>Clique sur une balise input de type image avec cet attribut d'identification</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 un 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> + + <p> +<a class="target" name="requete"> +<h2>Modifier la requête</h2> +</a> +</p> + <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> +<div class="copyright"> + Copyright<br>Marcus Baker, Jason Sweat, Perrick Penet 2004 + </div> +</body> +</html> |