1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 328 329
|
<?xml version="1.0" encoding="UTF-8"?>
<!-- EN-Revision: 24249 -->
<!-- Reviewed: no -->
<sect2 id="zend.test.phpunit.examples">
<title>Exemples</title>
<para>
Savoir comment configurer votre infrastructure de tests et comment faire des
assertions est seulement la moitié du travail ; maintenant il est temps de commencer à
regarder quelques scénarios réels de test pour voir comment vous pouvez les étendre.
</para>
<example id="zend.test.phpunit.examples.userController">
<title>Test d'un contrôleur "UserController"</title>
<para>
Considérons une tâche habituelle d'un site Web : l'authentification et
l'enregistrement d'utilisateurs. Dans notre exemple, nous avons défini un contrôleur
"<code>UserController</code>" pour gérer ceci, il requiert le conditions suivantes
:
</para>
<itemizedlist>
<listitem>
<para>
Si un utilisateur n'est pas authentifié, il sera toujours redirigé vers la
page de login, sans se soucier de l'action demandée.
</para>
</listitem>
<listitem>
<para>
La page avec le formulaire de login présente à la fois le formulaire de
login et le formulaire d'enregistrement.
</para>
</listitem>
<listitem>
<para>
Fournir une identification invalide entraîne un retour au formulaire de
login.
</para>
</listitem>
<listitem>
<para>
Une identification valide entraîne une redirection vers la page avec le
profil de l'utilisateur.
</para>
</listitem>
<listitem>
<para>
La page de profil peut être personnalisée pour contenir le nom
d'utilisateur.
</para>
</listitem>
<listitem>
<para>
Les utilisateurs déjà authentifiés qui accèdent à la page de login sont
redirigés vers leur page de profil.
</para>
</listitem>
<listitem>
<para>
En cas de déconnexion, un utilisateur est redirigé vers la page de
login.
</para>
</listitem>
<listitem>
<para>
Avec des données invalides, l'enregistrement doit entraîner un
échec.
</para>
</listitem>
</itemizedlist>
<para>
Nous pourrions, et devrions définir d'autres tests, mais ceux-ci suffiront pour
l'instant.
</para>
<para>
Pour notre application, nous définirons un plugin "<code>Initialize</code>", qui
fonctionne en <methodname>routeStartup()</methodname>. Ceci nous permet d'encapsuler notre fichier
d'amorçage dans une interface POO, et qui nous permet aussi de fournir par une solution
simple une fonction de rappel ("callback"). Regardons d'abord les bases de cette classe
:
</para>
<programlisting language="php"><![CDATA[
class Bugapp_Plugin_Initialize extends Zend_Controller_Plugin_Abstract
{
/**
* @var Zend_Config
*/
protected static $_config;
/**
* @var string Current environment
*/
protected $_env;
/**
* @var Zend_Controller_Front
*/
protected $_front;
/**
* @var string Path to application root
*/
protected $_root;
/**
* Constructor
*
* Initialize environment, root path, and configuration.
*
* @param string $env
* @param string|null $root
* @return void
*/
public function __construct($env, $root = null)
{
$this->_setEnv($env);
if (null === $root) {
$root = realpath(dirname(__FILE__) . '/../../../');
}
$this->_root = $root;
$this->initPhpConfig();
$this->_front = Zend_Controller_Front::getInstance();
}
/**
* Route startup
*
* @return void
*/
public function routeStartup(Zend_Controller_Request_Abstract $request)
{
$this->initDb();
$this->initHelpers();
$this->initView();
$this->initPlugins();
$this->initRoutes();
$this->initControllers();
}
// definition of methods would follow...
}
]]></programlisting>
<para>Ceci nous permet de créer un callback d'amorçage comme ce qui suit :</para>
<programlisting language="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
public function appBootstrap()
{
$controller = $this->getFrontController();
$controller->registerPlugin(
new Bugapp_Plugin_Initialize('development')
);
}
public function setUp()
{
$this->bootstrap = array($this, 'appBootstrap');
parent::setUp();
}
// ...
}
]]></programlisting>
<para>
Une fois ceci en place, nous pouvons écrire nos tests. Cependant, combien de ces
tests nécessiteront qu'un utilisateur soit connecté ? La solution la plus simple est
d'utiliser la logique de votre application pour faire ceci... et d'esquiver un peu par
l'utilisation des méthodes <methodname>resetResponse()</methodname> et <methodname>resetResponse()</methodname>,
qui vous permettront de distribuer une nouvelle requête.
</para>
<programlisting language="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
// ...
public function loginUser($user, $password)
{
$this->request->setMethod('POST')
->setPost(array(
'username' => $user,
'password' => $password,
));
$this->dispatch('/user/login');
$this->assertRedirectTo('/user/view');
$this->resetRequest()
->resetResponse();
$this->request->setPost(array());
// ...
}
// ...
}
]]></programlisting>
<para>Écrivons maintenant les tests :</para>
<programlisting language="php"><![CDATA[
class UserControllerTest extends Zend_Test_PHPUnit_ControllerTestCase
{
// ...
public function testCallWithoutActionShouldPullFromIndexAction()
{
$this->dispatch('/user');
$this->assertController('user');
$this->assertAction('index');
}
public function testLoginFormShouldContainLoginAndRegistrationForms()
{
$this->dispatch('/user');
$this->assertQueryCount('form', 2);
}
public function testInvalidCredentialsShouldResultInRedisplayOfLoginForm()
{
$request = $this->getRequest();
$request->setMethod('POST')
->setPost(array(
'username' => 'bogus',
'password' => 'reallyReallyBogus',
));
$this->dispatch('/user/login');
$this->assertNotRedirect();
$this->assertQuery('form');
}
public function testValidLoginShouldRedirectToProfilePage()
{
$this->loginUser('foobar', 'foobar');
}
public function testAuthenticatedUserShouldHaveCustomizedProfilePage()
{
$this->loginUser('foobar', 'foobar');
$this->request->setMethod('GET');
$this->dispatch('/user/view');
$this->assertNotRedirect();
$this->assertQueryContentContains('h2', 'foobar');
}
public function testAuthenticatedUsersShouldBeRedirectedToProfilePageWhenVisitingLoginPage()
{
$this->loginUser('foobar', 'foobar');
$this->request->setMethod('GET');
$this->dispatch('/user');
$this->assertRedirectTo('/user/view');
}
public function testUserShouldRedirectToLoginPageOnLogout()
{
$this->loginUser('foobar', 'foobar');
$this->request->setMethod('GET');
$this->dispatch('/user/logout');
$this->assertRedirectTo('/user');
}
public function testRegistrationShouldFailWithInvalidData()
{
$data = array(
'username' => 'This will not work',
'email' => 'this is an invalid email',
'password' => 'Th1s!s!nv@l1d',
'passwordVerification' => 'wrong!',
);
$request = $this->getRequest();
$request->setMethod('POST')
->setPost($data);
$this->dispatch('/user/register');
$this->assertNotRedirect();
$this->assertQuery('form .errors');
}
}
]]></programlisting>
<para>
Notez que ces tests sont laconiques, et, pour la plupart, ne recherchent pas le
contenu réel. Au lieu de cela, ils recherchent des objets construits dans la réponse -
codes et en-têtes de réponse, et noeuds DOM. Ceci vous permet de vérifier que la
structure est comme prévue - sans entraîner un échec dans vos tests à chaque fois qu'un
contenu est ajouté au site.
</para>
<para>
Notez également que nous utilisons la structure du document dans nos essais. Par
exemple, dans le test final, nous recherchons un formulaire qui a un noeud avec la
classe "errors" ; ceci nous permet de déterminer simplement la présence des erreurs de
validation de formulaire, et sans nous inquiéter de quelles erreurs spécifiques
pourraient avoir été levées.
</para>
<para>
Cette application <emphasis>peut</emphasis> utiliser une base de données. Si oui,
vous aurez besoin probablement d'un certain échafaudage pour s'assurer que la base de
données est dans une configuration initiale et testable au début de chaque essai.
PHPUnit fournit déjà une fonctionnalité pour faire ceci ; <ulink
url="http://www.phpunit.de/manual/3.4/en/database.html">lisez ceci dans la
documentation PHPUnit</ulink>. Nous recommandons d'utiliser une base de données séparée
pour les tests et pour la production, et recommandons en particulier d'employer un
fichier SQLite ou une base de données en mémoire, d'autant que les deux options
s'exécutent très bien, sans nécessité d'un serveur séparé, et peuvent utiliser la
plupart de la syntaxe <acronym>SQL</acronym>
</para>
</example>
</sect2>
<!--
vim:se ts=4 sw=4 et:
-->
|