Testing¶

Installation via Composer¶

Pendant longtemps, CakePHP 2.x a seulement supporté PHPUnit 3.7.x. Pour installer PHPUnit comme dépendance « development » via Composer, exécutez la commande suivante dans le même dossier que votre fichier composer.json:

php composer.phar require --dev phpunit/phpunit:"3.7.38"

Depuis CakePHP 2.10.0, un support basique de PHPUnit 4.x et 5.x a été ajouté. Pour mettre à jour PHPUnit et ses dépendances pour votre application, exécutez la commande suivante:

php composer.phar require --dev phpunit/phpunit:"4.* || 5.*" --update-with-dependencies

Cela installera soit PHPUnit 4.x, soit PHPUnit 5.x, en fonction de votre système et de la configuration de votre composer.json.

Installation via Package .phar¶

Vous pouvez également télécharger le fichier directement. Assurez-vous de récupérer la bonne version depuis https://phar.phpunit.de/. Assurez-vous également que /usr/local/bin est dans le include_path de votre fichier php.ini:

wget https://phar.phpunit.de/phpunit-3.7.38.phar -O phpunit.phar
chmod +x phpunit.phar
mv phpunit.phar /usr/local/bin/phpunit

Lancer les tests à partir d’un navigateur¶

CakePHP fournit une interface web pour lancer les tests, donc vous pouvez exécuter vos tests par le navigateur si vous êtes plus habitué à cet environnement. Vous pouvez accéder au web runner en allant sur http://localhost/votre_app/test.php. La localisation exacte du test.php va changer en fonction de votre configuration. Mais le fichier est au même niveau que index.php.

Une fois que vous chargé les tests runners, vous pouvez naviguer dans les suites test de App, Core et Plugin. Cliquer sur un cas de test individuel va lancer ce test et afficher les résultats.

Lancer les tests à partir d’une ligne de commande¶

CakePHP fournit un shell test pour lancer les tests. Vous pouvez lancer les tests de app, core et plugin facilement en utilisant le shell test. Il accepte aussi tous les arguments que vous vous attendez à trouver sur l’outil de ligne de commande du PHPUnit normal. A partir de votre répertoire app, vous pouvez faire ce qui suit pour lancer les tests:

# Lancer un test de model dans app
./Console/cake test app Model/Article

# Lancer un test de component dans un plugin
./Console/cake test DebugKit Controller/Component/ToolbarComponent

# Lancer le test de la classe de configuration dans CakePHP
./Console/cake test core Core/Configure

Vous pouvez aussi lancer le shell test dans le répertoire de projet racine. Cela vous montre une liste complète de tous les tests que vous avez actuellement. Vous pouvez ainsi choisir librement quel(s) test(s) lancer:

# Lancer test dans le répertoire de projet racine pour le dossier application appelé app
lib/Cake/Console/cake test app

# Lancer test dans le répertoire de projets racine pour une application dans ./myapp
lib/Cake/Console/cake test -app myapp app

./Console/cake test core Console/ConsoleOutput --filter testWriteArray

./Console/cake test app Model/Article --coverage-html webroot/coverage

Créer les fixtures¶

A la création d’une fixture, vous pouvez définir principalement deux choses: comment la table est créée (quels champs font partie de la table), et quels enregistrements seront remplis initialement dans la table. Créons notre première fixture, qui sera utilisée pour tester notre propre model Article. Crée un fichier nommé ArticleFixture.php dans votre répertoire app/Test/Fixture avec le contenu suivant:

class ArticleFixture extends CakeTestFixture {

      // Optionel
      // Définir cette propriété pour charger les fixtures dans une source
      // de données de test différente
      public $useDbConfig = 'test';
      public $fields = array(
          'id' => array('type' => 'integer', 'key' => 'primary'),
          'title' => array('type' => 'string', 'length' => 255, 'null' => false),
          'body' => 'text',
          'published' => array('type' => 'integer', 'default' => '0', 'null' => false),
          'created' => 'datetime',
          'updated' => 'datetime'
      );
      public $records = array(
          array('id' => 1, 'title' => 'First Article', 'body' => 'First Article Body', 'published' => '1', 'created' => '2007-03-18 10:39:23', 'updated' => '2007-03-18 10:41:31'),
          array('id' => 2, 'title' => 'Second Article', 'body' => 'Second Article Body', 'published' => '1', 'created' => '2007-03-18 10:41:23', 'updated' => '2007-03-18 10:43:31'),
          array('id' => 3, 'title' => 'Third Article', 'body' => 'Third Article Body', 'published' => '1', 'created' => '2007-03-18 10:43:23', 'updated' => '2007-03-18 10:45:31')
      );
 }

La propriété $useDbConfig définit la source de données que la fixture va utiliser. Si votre application utilise plusieurs sources de données, vous devriez faire correspondre les fixtures avec les sources de données du model, mais préfixé avec test_. Par exemple, si votre model utilise la source de données mydb, votre fixture devra utiliser la source de données test_mydb. Si la connexion test_mydb n’existe pas, vos models vont utiliser la source de données test par défaut. Les sources de données de fixture doivent être préfixées par test pour réduire la possibilité de trucher accidentellement toutes les données de votre application quand vous lancez des tests.

Nous utilisons $fields pour spécifier les champs qui feront partie de cette table, et comment ils sont définis. Le format utilisé pour définir ces champs est le même qu’utilisé avec CakeSchema. Les clés disponibles pour la définition de la table sont:

type

Type de données interne à CakePHP. Actuellement supportés:

• string: redirige vers VARCHAR.

• text: redirige vers TEXT.

• biginteger: redirige vers BIGINT.

• smallinteger: redirige vers SMALLINT

• tinyinteger: redirige vers TINYINT ou SMALLINT en fonction du moteur de base de données utilisé

• integer: redirige vers INT.

• float: redirige vers FLOAT.

• decimal: redirige vers DECIMAL.

• datetime: redirige vers DATETIME.

• timestamp: redirige vers TIMESTAMP.

• time: redirige vers TIME.

• date: redirige vers DATE.

• binary: redirige vers BLOB.

• boolean: redirige vers BOOLEAN (ou TINYINT pour MySQL).

key

Défini à primary pour que le champ soit en AUTO_INCREMENT, et une PRIMARY KEY pour la table.

length

Défini à la longueur spécifique que le champ doit prendre.

null

Défini soit à true (pour permettre les NULLs) soit à false (pour ne pas permettre les NULLs).

default

Valeur par défaut que le champ prend.

Nous pouvons définir un ensemble d’enregistrements qui seront remplis après que la table de fixture est créée. Le format est directement fairly forward, $records est un tableau d’enregistrements. Chaque item dans $records devrait être une unique ligne. A l’intérieur de chaque ligne, il devrait y avoir un tableau associatif des colonnes et valeurs pour la ligne. Gardez juste à l’esprit que chaque enregistrement dans le tableau $records doit avoir une clé pour chaque champ spécifié dans le tableau $fields. Si un champ pour un enregistrement particulier a besoin d’avoir une valeur null, spécifiez juste la valeur de cette clé à null.

Les données dynamiques et les fixtures¶

Depuis que les enregistrements pour une fixture sont déclarées en propriété de classe, vous ne pouvez pas facilement utiliser les fonctions ou autres données dynamiques pour définir les fixtures. Pour résoudre ce problème, vous pouvez définir $records dans la fonction init() de votre fixture. Par exemple, si vous voulez tous les timestamps créés et mis à jours pour refléter la date d’aujourd’hui, vous pouvez faire ce qui suit:

class ArticleFixture extends CakeTestFixture {

    public $fields = array(
        'id' => array('type' => 'integer', 'key' => 'primary'),
        'title' => array('type' => 'string', 'length' => 255, 'null' => false),
        'body' => 'text',
        'published' => array('type' => 'integer', 'default' => '0', 'null' => false),
        'created' => 'datetime',
        'updated' => 'datetime'
    );

    public function init() {
        $this->records = array(
            array(
                'id' => 1,
                'title' => 'First Article',
                'body' => 'First Article Body',
                'published' => '1',
                'created' => date('Y-m-d H:i:s'),
                'updated' => date('Y-m-d H:i:s'),
            ),
        );
        parent::init();
    }
}

Quand vous surchargez init(), rappelez-vous juste de toujours appeler parent::init().

Importer les informations de table et les enregistrements¶

Votre application peut avoir déjà des models travaillant avec des données réelles associées à eux, et vous pouvez décider de tester votre application avec ces données. Ce serait alors un effort dupliqué pour avoir à définir une définition de table et/ou des enregistrements sur vos fixtures. Heureusement, il y a une façon pour vous de définir cette définition de table et/ou d’enregistrements pour une fixture particulière venant d’un model existant ou d’une table existante.

Commençons par un exemple. Imaginons que vous ayez un model nommé Article disponible dans votre application (qui est lié avec une table nommée articles), on changerait le fixture donné dans la section précédente (app/Test/Fixture/ArticleFixture.php) en ce qui suit:

class ArticleFixture extends CakeTestFixture {
    public $import = 'Article';
}

Cette déclaration dit à la suite test d’importer la définition de votre table à partir de la table liée au model appelé Article. Vous pouvez utiliser tout model disponible dans votre application. La déclaration va seulement importer le schéma Article, et n’importe pas d’enregistrements. Pour importer les enregistrements, vous pouvez faire ce qui suit:

class ArticleFixture extends CakeTestFixture {
    public $import = array('model' => 'Article', 'records' => true);
}

Si d’un autre côté vous avez une table créée mais pas de model disponible pour elle, vous pouvez spécifier que votre import se fera en lisant l’information de la table à la place. Par exemple:

class ArticleFixture extends CakeTestFixture {
    public $import = array('table' => 'articles');
}

Va importer la définition de la table à partir de la table appelée “articles” en utilisant la connexion à la base de donnée CakePHP nommée “default”. Si vous voulez utiliser une connexion différente, utilisez:

class ArticleFixture extends CakeTestFixture {
    public $import = array('table' => 'articles', 'connection' => 'other');
}

Puisqu’on utilise votre connexion à la base de données CakePHP, s’il y a un préfixe de table déclaré, il sera automatiquement utilisé quand on récupère l’information de la table. Pour forcer la fixture et aussi importer ses enregistrements, changez l’importation en:

class ArticleFixture extends CakeTestFixture {
    public $import = array('table' => 'articles', 'records' => true);
}

Vous pouvez naturellement importer la définition de votre table à partir d’un model/d’une table existante, mais vous avez vos enregistrements directement définis dans le fixture comme il a été montré dans la section précédente. Par exemple:

class ArticleFixture extends CakeTestFixture {
    public $import = 'Article';
    public $records = array(
        array('id' => 1, 'title' => 'First Article', 'body' => 'First Article Body', 'published' => '1', 'created' => '2007-03-18 10:39:23', 'updated' => '2007-03-18 10:41:31'),
        array('id' => 2, 'title' => 'Second Article', 'body' => 'Second Article Body', 'published' => '1', 'created' => '2007-03-18 10:41:23', 'updated' => '2007-03-18 10:43:31'),
        array('id' => 3, 'title' => 'Third Article', 'body' => 'Third Article Body', 'published' => '1', 'created' => '2007-03-18 10:43:23', 'updated' => '2007-03-18 10:45:31')
    );
}

Charger les fixtures dans vos cas de test¶

Après avoir créé vos fixtures, vous voudrez les utiliser dans vos cas de test. Dans chaque cas de test vous devriez charger les fixtures dont vous aurez besoin. Vous devriez charger une fixture pour chaque model qui aura une requête lancée contre elle. Pour charger les fixtures, vous définissez la propriété $fixtures dans votre model:

class ArticleTest extends CakeTestCase {
    public $fixtures = array('app.article', 'app.comment');
}

Ce qui est au-dessus va charger les fixtures d’Article et de Comment à partir du répertoire de fixture de l’application. Vous pouvez aussi charger les fixtures à partir du coeur de CakePHP ou des plugins:

class ArticleTest extends CakeTestCase {
    public $fixtures = array('plugin.debug_kit.article', 'core.comment');
}

Utiliser le préfixe core va charger les fixtures à partir de CakePHP, et utiliser un nom de plugin en préfixe chargera le fixture à partir d’un plugin nommé.

Vous pouvez contrôler quand vos fixtures sont chargés en configurant CakeTestCase::$autoFixtures à false et plus tard les charger en utilisant CakeTestCase::loadFixtures():

class ArticleTest extends CakeTestCase {
    public $fixtures = array('app.article', 'app.comment');
    public $autoFixtures = false;

    public function testMyFunction() {
        $this->loadFixtures('Article', 'Comment');
    }
}

Depuis 2.5.0, vous pouvez charger les fixtures dans les sous-répertoires. Utiliser plusieurs répertoires peut faciliter l’organisation de vos fixtures si vous avez une application plus grande. Pour charger les fixtures dans les sous-répertoires, incluez simplement le nom du sous-répertoire dans le nom de la fixture:

class ArticleTest extends CakeTestCase {
    public $fixtures = array('app.blog/article', 'app.blog/comment');
}

Dans l’exemple ci-dessus, les deux fixtures seront chargés à partir de App/Test/Fixture/blog/.

Créer une méthode de test¶

Ajoutons maintenant une méthode pour tester la fonction published() dans le model Article. Modifier le fichier app/Test/Case/Model/ArticleTest.php afin qu’il ressemble maintenant à ceci:

App::uses('Article', 'Model');

class ArticleTest extends CakeTestCase {
    public $fixtures = array('app.article');

    public function setUp() {
        parent::setUp();
        $this->Article = ClassRegistry::init('Article');
    }

    public function testPublished() {
        $result = $this->Article->published(array('id', 'title'));
        $expected = array(
            array('Article' => array('id' => 1, 'title' => 'First Article')),
            array('Article' => array('id' => 2, 'title' => 'Second Article')),
            array('Article' => array('id' => 3, 'title' => 'Third Article'))
        );

        $this->assertEquals($expected, $result);
    }
}

Vous pouvez voir que nous avons ajouté une méthode appelée testPublished(). Nous commençons par créer une instance de notre model Article, et lançons ensuite notre méthode published(). Dans $expected, nous définissons ce que nous en attendons, ce qui devrait être le résultat approprié (que nous connaissons depuis que nous avons défini quels enregistrements sont remplis initialement dans la table articles.). Nous testons que les résultats correspondent à nos attentes en utilisant la méthode assertEquals. Regarder la section sur les Lancer les Tests pour plus d’informations sur la façon de lancer les cas de test.

Méthodes de Mocking des models¶

Il y aura des fois où vous voudrez mock les méhodes sur les models quand vous les testez. Vous devrez utiliser getMockForModel pour créer les mocks de test des models. Cela évite des problèmes avec les reflected properties that normal mocks have:

public function testSendingEmails() {
    $model = $this->getMockForModel('EmailVerification', array('send'));
    $model->expects($this->once())
        ->method('send')
        ->will($this->returnValue(true));

    $model->verifyEmail('[email protected]');
}

Simuler les requêtes GET¶

Comme vu dans l’exemple testIndexPostData() ci-dessus, vous pouvez utiliser testAction() pour tester les actions POST ainsi que les actions GET. En fournissant la clé data, la requête faite par le controller sera POST. Par défaut, toutes les requêtes seront des requêtes POST. Vous pouvez simuler une requête GET en configurant la méthode clé:

public function testAdding() {
    $data = array(
        'Post' => array(
            'title' => 'New post',
            'body' => 'Secret sauce'
        )
    );
    $this->testAction('/posts/add', array('data' => $data, 'method' => 'get'));
    // some assertions.
}

La clé data sera utilisée en paramètres de recherche de chaînes quand on va simuler une requête GET.

Choisir le type de retour¶

Vous pouvez choisir plusieurs façons pour inspecter le succès de l’action de votre controller. Chacun offre une manière différente de s’assurer que votre code fait ce que vous en attendez:

• vars Récupère l’ensemble des variables de vue.

• view Récupère la vue rendue, sans un layout.

• contents Récupère la vue rendue en incluant le layout.

• result Récupère la valeur de retour de l’action du controller. Utile pour tester les méthodes requestAction.

La valeur par défaut est result. Tant que votre type de retour n’est pas result, vous pouvez aussi accéder aux autres types de retour en propriétés dans les cas de test:

public function testIndex() {
    $this->testAction('/posts/index');
    $this->assertInternalType('array', $this->vars['posts']);
}

Utiliser mocks avec testAction¶

Il y aura des fois où vous voudrez remplacer les components ou les models avec soit des objets partiellement mocké, soit des objets complètement mockés. Vous pouvez faire ceci en utilisant ControllerTestCase::generate(). generate() fait le sale boulot afin de générer les mocks sur votre controller. Si vous décidez de générer un controller à utiliser dans les tests, vous pouvez générer les versions mockés de ses models et components avec ceci:

$Posts = $this->generate('Posts', array(
    'methods' => array(
        'isAuthorized'
    ),
    'models' => array(
        'Post' => array('save')
    ),
    'components' => array(
        'RequestHandler' => array('isPut'),
        'Email' => array('send'),
        'Session'
    )
));

Ce qui est au-dessus créerait un PostsController mocké, stubbing out la méthode isAuthorized. Le model Post attaché aura un save() stubbed, et les components attachés auront leurs méthodes respectives stubbed. Vous pouvez choisir de stub une classe entière en ne leur passant pas les méthodes, comme Session dans l’exemple ci-dessus.

Les controllers générés sont automatiquement utilisés en tant que controller de test à tester. Pour activer la génération automatique, définissez la variable autoMock dans le cas de test à true. Si autoMock est à false, votre controller original sera utilisé dans le test.

La réponse objet dans le controller généré est toujours remplacée par un mock qui n’envoie pas les headers. Après utilisation de generate() ou testAction(), vous pouvez accéder à l’objet controller à $this->controller.

Un exemple plus complexe¶

Dans sa plus simple forme, testAction() lancera PostsController::index() dans votre controller de test (ou en générera un automatiquement), en incluant tous les models mockés et les components. Les résultats du test sont stockés dans les propriétés vars, contents, view, et return. Une propriété headers est aussi disponible qui vous donne accès à headers qui aurait été envoyée, vous permettant de vérifier les redirects:

public function testAdd() {
    $Posts = $this->generate('Posts', array(
        'components' => array(
            'Session',
            'Email' => array('send')
        )
    ));
    $Posts->Session
        ->expects($this->once())
        ->method('setFlash');
    $Posts->Email
        ->expects($this->once())
        ->method('send')
        ->will($this->returnValue(true));

    $this->testAction('/posts/add', array(
        'data' => array(
            'Post' => array('title' => 'New Post')
        )
    ));
    $this->assertContains('/posts', $this->headers['Location']);
}

public function testAddGet() {
    $this->testAction('/posts/add', array(
        'method' => 'GET',
        'return' => 'contents'
    ));
    $this->assertRegExp('/<html/', $this->contents);
    $this->assertRegExp('/<form/', $this->view);
}

Cet exemple montre une utilisation légèrement plus complexe des méthodes testAction() et generate(). Tout d’abord, nous générons un controller de test et mock le SessionComponent. Maintenant que SessionComponent est mocké, nous avons la possibilité de lancer des méthodes de test dessus. En supposant que PostsController::add() nous redirige à l’index, envoie un email et définit un message flash, le test va passer. Pour le bénéfice de l’exemple, nous vérifions aussi si le layout a été chargé en vérifiant les contenus entièrement rendus, et vérifions la vue pour un tag form. Comme vous pouvez le voir, votre liberté pour tester les controllers et facilement mocker ses classes est grandement étendue avec ces changements.

Quand vous faîtes des tests de controller en utilisant les mocks qui utilisent les méthodes statiques, vous devrez utiliser une méthode différente pour inscrire vos attentes de mock. Par exemple si vous voulez mock out AuthComponent::user() vous devrez faire ce qui suit:

public function testAdd() {
    $Posts = $this->generate('Posts', array(
        'components' => array(
            'Session',
            'Auth' => array('user')
        )
    ));
    $Posts->Auth->staticExpects($this->any())
        ->method('user')
        ->with('id')
        ->will($this->returnValue(2));
}

En utilisant staticExpects vous serez capable de mock et de manipuler les méthodes statiques sur les components et models.

Tester un Controller de Réponse JSON¶

JSON est un format sympa et courant à utiliser quand on construit un service web. Tester les endpoints de votre service web est très simple avec CakePHP. Commençons par un exemple de controller simple qui réponde dans JSON:

class MarkersController extends AppController {
    public $autoRender = false;
    public function index() {
        $data = $this->Marker->find('first');
        $this->response->body(json_encode($data));
    }
}

Maintenant nous créons le fichier app/Test/Case/Controller/MarkersControllerTest.php et nous assurons que notre service web retourne la réponse appropriée:

class MarkersControllerTest extends ControllerTestCase {
    public function testIndex() {
        $result = $this->testAction('/markers/index.json');
        $result = json_decode($result, true);
        $expected = array(
            'Marker' => array('id' => 1, 'lng' => 66, 'lat' => 45),
        );
        $this->assertEquals($expected, $result);
    }
}

Créer un job¶

Commençons par créer un job pour votre application, et connectons votre répertoire afin que jenkins puisse accéder à votre code.

Ajouter une config de base de données de test¶

Utiliser une base de données séparée juste pour Jenkins est généralement une bonne idée, puisque cela évite au sang de couler et évite un certain nombre de problèmes basiques. Une fois que vous avez créé une nouvelle base de données dans un serveur de base de données auquel jenkins peut accéder (habituellement localhost). Ajoutez une étape de script shell au build qui contient ce qui suit:

cat > app/Config/database.php <<'DATABASE_PHP'
<?php
class DATABASE_CONFIG {
    public $test = array(
        'datasource' => 'Database/Mysql',
        'host'       => 'localhost',
        'database'   => 'jenkins_test',
        'login'      => 'jenkins',
        'password'   => 'cakephp_jenkins',
        'encoding'   => 'utf8'
    );
}
DATABASE_PHP

Cela s’assure que vous aurez toujours la bonne configuration de la base de données dont Jenkins a besoin. Faites la même chose pour tout autre fichier de configuration dont vous auriez besoin. Il est souvent une bonne idée de supprimer et re-créer la base de données avant chaque build aussi. Cela vous évite des échecs de chaînes, où un buid cassé entraîne l’echec des autres. Ajoutez une autre étape de script shell au build qui contient ce qui suit:

mysql -u jenkins -pcakephp_jenkins -e 'DROP DATABASE IF EXISTS jenkins_test; CREATE DATABASE jenkins_test';

Ajouter vos tests¶

Ajoutez une autre étape de script shell à votre build. Dans cette étape, lancez les tests pour votre application. Créer un fichier de log junit, ou clover coverage est souvent un bonus sympa, puisqu’il vous donne une vue graphique sympa des résultats de votre test:

app/Console/cake testsuite app AllTests \
--stderr \
--log-junit junit.xml \
--coverage-clover clover.xml

Si vous utilisez le clover coverage, ou les résultats junit, assurez-vous de les configurer aussi dans Jenkins. Ne pas configurer ces étapes signifiera que vous ne verrez pas les résultats.

Lancer un build¶

Vous devriez être capable de lancer un build maintenant. Vérifiez la sortie de la console et faites tous les changements nécessaires pour obtenir un build précédent.