15. Cookbook¶

15.1. Changer l’espace de nom par défaut¶

Au début de l’exécution d’une classe de test, atoum calcule le nom de la classe testée. Pour cela, par défaut, il remplace dans le nom de la classe de test l’expression régulière #(?:^|\\\)tests?\\\units?\\#i par le caractère \.

Ainsi, si la classe de test porte le nom vendor\project\tests\units\foo, il en déduira que la classe testée porte le nom vendor\project\foo. Cependant, il peut être nécessaire que l’espace de nom des classes de test ne corresponde pas à cette expression régulière, et dans ce cas, atoum s’arrête alors avec le message d’erreur suivant :

> exception 'mageekguy\atoum\exceptions\runtime' with message 'Test class 'project\vendor\my\tests\foo' is not in a namespace which match pattern '#(?:^|\\)ests?\\unit?s\#i'' in /path/to/unit/tests/foo.php
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Il faut donc modifier l’expression régulière utilisée, ceci est possible de plusieurs manières. Le plus simple est de faire appel à l’annotation @namespace appliquée à la classe de test, de la manière suivante :

<?php

namespace vendor\project\my\tests;

require_once __DIR__ . '/atoum.phar';

use mageekguy\atoum;

/**
 * @namespace \my\tests
 */
abstract class aClass extends atoum
{
   public function testBar()
   {
      /* ... */
   }
}

Cette méthode est simple et rapide à mettre en œuvre, mais elle présente l’inconvénient de devoir être répétée dans chaque classe de test, ce qui peut compliquer leur maintenance en cas de modification de leur espace de nom. L’alternative consiste à faire appel à la méthode atoum\test::setTestNamespace() dans le constructeur de la classe, de cette manière :

<?php

namespace vendor\project\my\tests;

require_once __DIR__ . '/atoum.phar';

use mageekguy\atoum;

abstract class aClass extends atoum
{
   public function __construct(score $score = null, locale $locale = null, adapter $adapter = null)
   {
      $this->setTestNamespace('\\my\\tests');

      parent::__construct($score, $locale, $adapter);
   }

   public function testBar()
   {
      /* ... */
   }
}

La méthode atoum\test::setTestNamespace() accepte en effet un unique argument qui doit être l’expression régulière correspondant à l’espace de nom de votre classe de test. Et pour ne pas avoir à répéter l’appel à cette méthode dans chaque classe de test, il suffit de le faire une bonne fois pour toutes dans une classe abstraite de la manière suivante :

<?php

namespace vendor\project\my\tests;

require_once __DIR__ . '/atoum.phar';

use mageekguy\atoum;

abstract class Test extends atoum
{
   public function __construct(score $score = null, locale $locale = null, adapter $adapter = null)
   {
       $this->setTestNamespace('\\my\\tests');

      parent::__construct($score, $locale, $adapter);
   }
}

Ainsi, vous n’aurez plus qu’à faire dériver vos classes de tests unitaires de cette classe abstraite :

<?php

namespace vendor\project\my\tests\modules;

require_once __DIR__ . '/atoum.phar';

use mageekguy\atoum;
use vendor\project\my\tests;

class aModule extends tests\Test
{
   public function testDoSomething()
   {
      /* ... */
   }
}

En cas de modification de l’espace de nommage réservé aux tests unitaires, il ne sera donc nécessaire de ne modifier que la classe abstraite.

De plus, il n’est pas obligatoire d’utiliser une expression régulière, que ce soit au niveau de l’annotation @namespace ou de la méthode atoum\test::setTestNamespace(), et une simple chaîne de caractères peut également fonctionner.

En effet, atoum fait appel par défaut à une expression régulière afin que son utilisateur puisse utiliser par défaut un large panel d’espaces de nom sans avoir besoin de le configurer à ce niveau. Cela lui permet donc d’accepter par exemple sans configuration particulière les espaces de nomsuivants :

test\unit\
Test\Unit\
tests\units\
Tests\Units\
TEST\UNIT\

Cependant, en règle général, l’espace de nom utilisé pour les classes de test est fixe et il n’est donc pas nécessaire de recourir à une expression régulière si celle par défaut ne convient pas. Dans notre cas, elle pourrait être remplacée par la chaîne de caractères my\tests, par exemple grâce à l’annotation @namespace :

<?php

namespace vendor\project\my\tests;

require_once __DIR__ . '/atoum.phar';

use mageekguy\atoum;

/**
 * @namespace \my\tests\
 */
abstract class aClass extends atoum
{
   public function testBar()
   {
      /* ... */
   }
}

15.2. Test d’un singleton¶

Pour tester si une méthode retourne bien systématiquement la même instance d’un objet, vérifiez que deux appels successifs à la méthode testée sont bien identiques.

<?php
$this
    ->object(\Singleton::getInstance())
        ->isInstanceOf('Singleton')
        ->isIdenticalTo(\Singleton::getInstance())
;

15.3. Hook git¶

Une bonne pratique, lorsqu’on utilise un logiciel de gestion de versions, est de ne jamais ajouter à un dépôt du code non fonctionnel, afin de pouvoir récupérer une version propre et utilisable du code à tout moment et à n’importe quel endroit de l’historique du dépôt.

Cela implique donc, entre autres, que les tests unitaires doivent passer dans leur intégralité avant que les fichiers créés ou modifiés soient ajoutés au dépôt et, en conséquence, le développeur est censé exécuter les tests unitaires avant d’intégrer son code dans le dépôt.

Cependant, dans les faits, il est très facile pour le développeur d’omettre cette étape, et votre dépôt peut donc contenir à plus ou moins brève échéance du code ne respectant pas les contraintes imposées par les tests unitaires.

Heureusement, les logiciels de gestion de versions en général et Git en particulier disposent d’un mécanisme, connu sous le nom de hook de pré-commit permettant d’exécuter automatiquement des tâches lors de l’ajout de code dans un dépôt.

L’installation d’un hook de pré-commit est très simple et se déroule en deux étapes.

15.3.1. Étape 1 : Création du script à exécuter¶

Lors de l’ajout de code à un dépôt, Git recherche le fichier .git/hook/pre-commit à la racine du dépôt et l’exécute s’il existe et qu’il dispose des droits nécessaires.

Pour mettre en place le hook, il vous faut donc créer le fichier .git/hook/pre-commit et y ajouter le code suivant :

Le code ci-dessous suppose que vos tests unitaires sont dans des fichiers ayant l’extension .php et dans des répertoires dont le chemin contient /Tests/Units/. Si ce n’est pas votre cas, vous devrez modifier le script suivant votre contexte.

Note

Dans l’exemple ci-dessus, les fichiers de test doivent inclure atoum pour que le hook fonctionne.

Les tests étant exécutés très rapidement avec atoum, on peut donc lancer l’ensemble des tests unitaires avant chaque commit avec un hook comme celui-ci :

#!/bin/sh
./bin/atoum -d tests/

15.3.2. Étape 2 : Ajout des droits d’exécution¶

Pour être utilisable par Git, le fichier .git/hook/pre-commit doit être rendu exécutable à l’aide de la commande suivante, exécutée en ligne de commande à partir du répertoire de votre dépôt :

$ chmod u+x `.git/hook/pre-commit`

À partir de cet instant, les tests unitaires contenus dans les répertoires dont le chemin contient /Tests/Units/ seront lancés automatiquement lorsque vous effectuerez la commande git commit, si des fichiers ayant l’extension .php ont été modifiés.

Et si d’aventure un test ne passe pas, les fichiers ne seront pas ajoutés au dépôt. Il vous faudra alors effectuer les corrections nécessaires, utiliser la commande git add sur les fichiers modifiés et utiliser à nouveau git commit.

15.4. Utilisation dans behat¶

Les asserters d’atoum sont très facilement utilisables hors de vos tests unitaires classiques. Il vous suffit d’importer la classe mageekguyatoumasserter en n’oubliant pas d’assurer le chargement des classes nécessaires (atoum fournit une classe d’autoload disponible dans classes/autoloader.php). L’exemple suivant illustre cette utilisation des asserters atoum à l’intérieur de vos steps Behat.

15.4.1. Installation¶

Installez simplement atoum et Behat dans votre projet via pear, git clone, zip… Voici un exemple avec le gestionnaire de dépendances Composer :

"require-dev": {
        "behat/behat": "2.4@stable",
        "atoum/atoum": "~2.5"
}

Il est évidemment nécessaire de remettre à jour vos dépendances composer en lançant la commande :

$ php composer.phar update

15.4.2. Configuration¶

Comme mentionné en introduction, il suffit d’importer la classe d’asserter et d’assurer le chargement des classes d’atoum. Pour Behat, la configuration des asserters s’effectue dans votre classe FeatureContext.php (située par défaut dans le répertoire /RACINE DE VOTRE PROJET/features/bootstrap/).

<?php

use Behat\Behat\Context\ClosuredContextInterface,
    Behat\Behat\Context\TranslatedContextInterface,
    Behat\Behat\Context\BehatContext,
    Behat\Behat\Exception\PendingException,
    Behat\Behat\Context\Step;
use Behat\Gherkin\Node\PyStringNode,
    Behat\Gherkin\Node\TableNode;

use atoum\asserter; // <- atoum asserter

require_once __DIR__ . '/../../vendor/atoum/atoum/classes/autoloader.php'; // <- autoload

class FeatureContext extends BehatContext
{
    private $assert;

    public function __construct(array $parameters)
    {
        $this->assert = new asserter\generator();
    }
}

15.4.3. Utilisation¶

Après ces 2 étapes particulièrement triviales, vos steps peuvent s’enrichir des asserters atoum :

<?php

// ...

class FeatureContext extends BehatContext
{//...

    /**
     * @Then /^I should get a good response using my favorite "([^"]*)"$/
     */
    public function goodResponse($contentType)
    {
        $this->assert
            ->integer($response->getStatusCode())
                ->isIdenticalTo(200)
            ->string($response->getHeader('Content-Type'))
                ->isIdenticalTo($contentType);
    }
}

Encore une fois, ceci n’est qu’un exemple spécifique à Behat mais il reste valable pour tous les besoins d’utilisation des asserters d’atoum hors contexte initial.

15.5. Utilisation dans des outils d’intégration continue (CI)¶

15.5.1. Utilisation dans Jenkins (ou Hudson)¶

Il est très simple d’intégrer les résultats de tests atoum à Jenkins (ou Hudson) en tant que résultats xUnit.

15.5.1.1. Étape 1 : Ajout d’un rapport xUnit à la configuration atoum¶

Comme pour les autres rapports de couverture, vous pouvez définir des rapports spécifiques dans la configuration.

15.5.1.1.1. Si vous n’avez pas de fichier de configuration¶

Si vous ne disposez pas encore d’un fichier de configuration pour atoum, nous vous recommandons d’extraire le répertoire ressource d’atoum dans celui de votre choix à l’aide de la commande suivante :

Si vous utilisez l’archive Phar d’atoum :

$ php atoum.phar --extractRessourcesTo /tmp/atoum-src
$ cp /tmp/atoum-src/resources/configurations/runner/xunit.php.dist /mon/projet/.atoum.php

Si vous utilisez les sources d’atoum :

$ cp /chemin/vers/atoum/resources/configurations/runner/xunit.php.dist /mon/projet/.atoum.php

Vous pouvez également copier le fichier directement depuis le dépôt Github

Il ne vous reste plus qu’à éditer ce fichier pour choisir l’emplacement où atoum génèrera le rapport xUnit. Ce fichier est prêt à l’emploi, avec lui, vous conservez le rapport par défaut d’atoum et vous obtiendrez un rapport xUnit à la suite de chaque lancement des tests.

15.5.1.1.2. Si vous avez déjà un fichier de configuration¶

Si vous disposez déjà d’un fichier de configuration, il vous suffit d’y ajouter les lignes suivantes :

<?php

//...

/*
 * Xunit report
 */
$xunit = new atoum\reports\asynchronous\xunit();
$runner->addReport($xunit);

/*
 * Xunit writer
 */
$writer = new atoum\writers\file('/chemin/vers/le/rapport/atoum.xunit.xml');
$xunit->addWriter($writer);

15.5.1.2. Étape 2 : Tester la configuration¶

Pour tester cette configuration, il suffit de lancer atoum en lui précisant le fichier de configuration que vous souhaitez utiliser :

$ ./bin/atoum -d /chemin/vers/les/tests/units -c /chemin/vers/la/configuration.php

Note

Si vous avez nommé votre fichier de configuration .atoum.php, atoum le chargera automatiquement. Le paramètre -c est donc optionnel dans ce cas. Pour qu’atoum charge automatiquement ce fichier, vous devrez lancer les tests à partir du dossier où se trouve le fichier .atoum.php ou d’un de ses enfants.

À la fin de l’exécution des tests, vous devriez voir le rapport xUnit dans le répertoire indiqué dans le fichier de configuration.

15.5.1.3. Étape 3 : Lancement des tests via Jenkins (ou Hudson)¶

Il existe pour cela plusieurs possibilités selon la façon dont vous construisez votre projet :

Si vous utilisez un script, il vous suffit d’y ajouter la commande précédente.
Si vous passez par un utilitaire tel que phing ou ant, il suffit d’ajouter une tâche exec :

<target name="unitTests">
  <exec executable="/usr/bin/php" failonerror="yes" failifexecutionfails="yes">
    <arg line="/path/to/atoum.phar -p /path/to/php -d /path/to/test/folder -c /path/to/atoumConfig.php" />
  </exec>
</target>

Vous noterez l’ajout du paramètre -p /chemin/vers/php qui permet d’indiquer à atoum le chemin vers le binaire PHP qu’il doit utiliser pour exécuter les tests unitaires.

15.5.1.4. Étape 4 : Publier le rapport avec Jenkins (ou Hudson)¶

Il suffit tout simplement d’activer la publication des rapports au format JUnit ou xUnit, en fonction du plug-in que vous utilisez, en lui indiquant le chemin d’accès au fichier généré par atoum.

15.5.2. Utilisation avec Travis-ci¶

Il est assez simple d’utiliser atoum dans l’outil qu’est Travis-CI. En effet, l’ensemble des étapes est indiqué dans la documentation de travis : * Créer votre fichier .travis.yml dans votre projet; * Ajoutez-y les deux lignes suivantes :

before_script: wget http://downloads.atoum.org/nightly/atoum.phar
script: php atoum.phar

Voici un exemple de fichier .travis.yml dont les tests présents dans le dossier tests seront exécuter.

language: php
php:
  - 5.4
  - 5.5
  - 5.6

before_script: wget http://downloads.atoum.org/nightly/atoum.phar
script: php atoum.phar -d tests/

15.6. Utilisation avec Phing ¶

La suite de tests de atoum peut facilement être exécutée au sein de votre configuration phing via l’intégration de la tâche phing/AtoumTask.php. Un exemple valide peut être trouvé dans le fichier resources/phing/build.xml.

Vous devez néanmoins enregistrer votre tâche personnalisée en utilisant taskdef , une tâche native de phing :

<taskdef name="atoum" classpath="vendor/atoum/atoum/resources/phing" classname="AtoumTask"/>

Ensuite vous pouvez l’utiliser à l’intérieur de l’une de vos étapes du fichier de build :

<target name="test">
  <atoum
    atoumautoloaderpath="vendor/atoum/atoum/classes/autoloader.php"
    phppath="/usr/bin/php"
    codecoverage="true"
    codecoveragereportpath="reports/html/"
    showcodecoverage="true"
    showmissingcodecoverage="true"
    maxchildren="5"
  >
    <fileset dir="tests/units/">
      <include name="**/*.php"/>
    </fileset>
  </atoum>
</target>

Les chemins donnés dans cet exemple a été pris à partir d’une installation standard via composer. Tous les paramètres possibles sont définis ci-dessous, vous pouvez modifier les valeurs ou en omettre certains et hériter des valeurs par défaut. Il y a trois types de paramètres :

15.6.1. Configuration d’atoum¶

bootstrap: fichier de bootstrap à inclure, exécuté avant chaque méthode de test
- default: .bootstrap.atoum.php
atoumpharpath: si atoum est utilisé au travers d’un phar, chemin vers celui-ci
atoumautoloaderpath: fichier d’autoloader, le fichier est exécuté avant chaque méthode de test
- default: .autoloader.atoum.php
phppath: chemin vers l’exécutable php
maxchildren: nombre maximum de sous-process qui peuvent tourner simultanément

15.6.2. Flags¶

codecoverage: active la couverture de code(uniquement si XDebug est disponible)
- default: false
showcodecoverage: montre le rapport de couverture de code
- default: true
showduration: montre la durée de l’exécution des tests
- default: true
showmemory: affiche la consommation mémoire
- default: true
showmissingcodecoverage: montre la couverture de code manquante
- default: true
showprogress: affiche la barre de progression de l’exécution des tests
- default: true
branchandpathcoverage: active la couverture de code sur les chemins et branches
- default: false
telemetry: active le rapport telemetry (l’extension atoum/reports-extension doit être installée)
- default: false

15.6.3. Rapports¶

codecoveragexunitpath: chemin vers le rapport xunit
codecoveragecloverpath: chemin vers le rapport clover
Couverture de code basic
- codecoveragereportpath: chemin vers le rapport html
- codecoveragereporturl: url dans le rapport HTML
Couverture de code treemap:
- codecoveragetreemappath: chemin vers le rapport treemap
- codecoveragetreemapurl: url pour le treemap
Couverture de code avancée
- codecoveragereportextensionpath: chemin vers le rapport html
- codecodecoveragereportextensionurl: url du rapport HTML
Telemetry
- telemetryprojectname: nom du projet a envoyer à telemetry

15.7. Utilisation avec des frameworks¶

15.7.1. Utilisation avec ez Publish¶

15.7.1.1. Étape 1 : Installation d’atoum au sein d’eZ Publish¶

Le framework eZ Publish possède déjà un répertoire dédié aux tests, nommé logiquement tests. C’est donc dans ce répertoire que devra être placé l”archive PHAR d’atoum. Les fichiers de tests unitaires utilisant atoum seront quant à eux placés dans un sous-répertoire tests/atoum afin qu’ils ne soient pas en conflit avec l’existant.

15.7.1.2. Étape 2 : Création de la classe de test de base¶

Une classe de test basée sur atoum doit étendre la classe \mageekguy\atoum\test. Toutefois, celle-ci ne tient pas compte des spécifications de eZ Publish. . Il est donc nécessaire de définir une classe de test de base, dérivée de \mageekguy\atoum\test, qui prendra en compte ces spécifités et donc dérivera l’ensemble des classes de tests unitaires. Pour cela, il suffit de définir la classe suivante dans le fichier tests\atoum\test.php :

<?php

namespace ezp;

use mageekguy\atoum;

require_once __DIR__ . '/atoum.phar';

// Autoloading : eZ
require 'autoload.php';

if ( !ini_get( "date.timezone" ) )
{
        date_default_timezone_set( "UTC" );
}

require_once( 'kernel/common/i18n.php' );

\eZContentLanguage::setCronjobMode();

/**
 * @abstract
 */
abstract class test extends atoum\test
{
}

?>

15.7.1.3. Étape 3 : Création d’une classe de test¶

Par défaut, atoum demande à ce que les classes de tests unitaires soient dans un espace de noms contenant test(s)unit(s), afin de pouvoir déduire le nom de la classe testée. À titre d’exemple, l’espace de noms nomprojet sera utilisé dans ce qui suit. Pour plus de simplicité, il est de plus conseillé de calquer l’arborescence des classes de test sur celle des classes testées, afin de pouvoir localiser rapidement la classe de test d’une classe, et inversement.

<?php

namespace nomdeprojet\tests\units;

require_once '../test.php';

use ezp;

class cache extends ezp\test
{
   public function testClass()
   {
          $this->assert->hasMethod('__construct');
   }
}

15.7.1.4. Étapes 4 : Exécution des tests unitaires¶

Une fois une classe de test créée, il suffit d’exécuter en ligne de commande l’instruction ci-dessous pour lancer le test, en se plaçant à la racine du projet :

# php tests/atoum/atoum.phar -d tests/atoum/units

Merci Jérémy Poulain pour ce tutoriel.

15.7.2. Utilisation avec Symfony 2¶

Si vous souhaitez utiliser atoum au sein de vos projets Symfony, vous pouvez installer le Bundle AtoumBundle.

Si vous souhaitez installer et configurer atoum manuellement, voici comment faire.

15.7.2.1. Étape 1: installation d’atoum¶

Si vous utilisez Symfony 2.0, téléchargez l’archive PHAR et placez-la dans le répertoire vendor qui est à la racine de votre projet.

Si vous utilisez Symfony 2.1+, ajoutez atoum dans votre fichier composer.json.

15.7.2.2. Étape 2: création de la classe de test¶

Imaginons que nous voulions tester cet Entity:

<?php
// src/Acme/DemoBundle/Entity/Car.php
namespace Acme\DemoBundle\Entity;

use Doctrine\ORM\Mapping as ORM;

/**
 * Acme\DemoBundle\Entity\Car
 * @ORM\Table(name="car")
 * @ORM\Entity(repositoryClass="Acme\DemoBundle\Entity\CarRepository")
 */
class Car
{
    /**
     * @var integer $id
     * @ORM\Column(name="id", type="integer")
     * @ORM\Id
     * @ORM\GeneratedValue(strategy="AUTO")
     */
    private $id;

    /**
     * @var string $name
     * @ORM\Column(name="name", type="string", length=255)
     */
    private $name;

    /**
     * @var integer $max_speed
     * @ORM\Column(name="max_speed", type="integer")
     */

    private $max_speed;
}

Note

Pour plus d’informations sur la création d’Entity dans Symfony 2, référez vous au manuel officiel

Créez le répertoire Tests/Units dans votre Bundle (par exemple src/Acme/DemoBundle/Tests/Units). C’est dans ce répertoire que seront stockés tous les tests de ce Bundle.

Créez un fichier Test.php qui servira de base à tous les futurs tests de ce Bundle.

<?php
// src/Acme/DemoBundle/Tests/Units/Test.php
namespace Acme\DemoBundle\Tests\Units;

// On inclus et active le class loader
require_once __DIR__ . '/../../../../../vendor/symfony/symfony/src/Symfony/Component/ClassLoader/UniversalClassLoader.php';

$loader = new \Symfony\Component\ClassLoader\UniversalClassLoader();

$loader->registerNamespaces(
    array(
        'Symfony'         => __DIR__ . '/../../../../../vendor/symfony/src',
        'Acme\DemoBundle' => __DIR__ . '/../../../../../src'
    )
);

$loader->register();

use mageekguy\atoum;

// Pour Symfony 2.0 uniquement !
require_once __DIR__ . '/../../../../../vendor/atoum.phar';

abstract class Test extends atoum
{
    public function __construct(
        adapter $adapter = null,
        annotations\extractor $annotationExtractor = null,
        asserter\generator $asserterGenerator = null,
        test\assertion\manager $assertionManager = null,
        \closure $reflectionClassFactory = null
    )
    {
        $this->setTestNamespace('Tests\Units');
        parent::__construct(
            $adapter,
            $annotationExtractor,
            $asserterGenerator,
            $assertionManager,
            $reflectionClassFactory
        );
    }
}

Note

L’inclusion de l’archive PHAR d’atoum n’est nécessaire que pour Symfony 2.0. Supprimez cette ligne dans le cas où vous utilisez Symfony 2.1+.

Note

Par défaut, atoum utilise le namespace tests/units pour les tests. Or Symfony 2 et son class loader exige des majuscules au début des noms. Pour cette raison, nous changeons le namespace des tests grâce à la méthode setTestNamespace(“TestsUnits”).

15.7.2.3. Étape 3: écriture d’un test¶

Dans le répertoire Tests/Units, il vous suffit de recréer l’arborescence des classes que vous souhaitez tester (par exemple src/Acme/DemoBundle/Tests/Units/Entity/Car.php).

Créons notre fichier de test:

<?php
// src/Acme/DemoBundle/Tests/Units/Entity/Car.php
namespace Acme\DemoBundle\Tests\Units\Entity;

require_once __DIR__ . '/../Test.php';

use Acme\DemoBundle\Tests\Units\Test;

class Car extends Test
{
    public function testGetName()
    {
        $this
            ->if($car = new \Acme\DemoBundle\Entity\Car())
            ->and($car->setName('Batmobile'))
                ->string($car->getName())
                    ->isEqualTo('Batmobile')
                    ->isNotEqualTo('De Lorean')
        ;
    }
}

15.7.2.4. Étape 4: lancement des tests¶

Si vous utilisez Symfony 2.0:

# Lancement des tests d'un fichier
$ php vendor/atoum.phar -f src/Acme/DemoBundle/Tests/Units/Entity/Car.php

# Lancement de tous les tests du Bundle
$ php vendor/atoum.phar -d src/Acme/DemoBundle/Tests/Units

Si vous utilisez Symfony 2.1+:

# Lancement des tests d'un fichier
$ ./bin/atoum -f src/Acme/DemoBundle/Tests/Units/Entity/Car.php

# Lancement de tous les tests du Bundle
$ ./bin/atoum -d src/Acme/DemoBundle/Tests/Units

Note

Vous pouvez obtenir plus d’informations sur le lancement des tests dans le chapitre qui y est consacré.

Dans tous les cas, voilà ce que vous devriez obtenir:

> PHP path: /usr/bin/php
> PHP version:
> PHP 5.3.15 with Suhosin-Patch (cli) (built: Aug 24 2012 17:45:44)
===================================================================
> Copyright (c) 1997-2012 The PHP Group
=======================================
> Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies
===============================================================
>     with Xdebug v2.1.3, Copyright (c) 2002-2012, by Derick Rethans
====================================================================
> Acme\DemoBundle\Tests\Units\Entity\Car...
[S___________________________________________________________][1/1]
> Test duration: 0.01 second.
=============================
> Memory usage: 0.50 Mb.
========================
> Total test duration: 0.01 second.
> Total test memory usage: 0.50 Mb.
> Code coverage value: 42.86%
> Class Acme\DemoBundle\Entity\Car: 42.86%
==========================================
> Acme\DemoBundle\Entity\Car::getId(): 0.00%
--------------------------------------------
> Acme\DemoBundle\Entity\Car::setMaxSpeed(): 0.00%
--------------------------------------------------
> Acme\DemoBundle\Entity\Car::getMaxSpeed(): 0.00%
--------------------------------------------------
> Running duration: 0.24 second.
Success (1 test, 1/1 method, 0 skipped method, 4 assertions) !

15.7.3. Utilisation avec symfony 1.4¶

Si vous souhaitez utiliser atoum au sein de vos projets Symfony 1.4, vous pouvez installer le plugin sfAtoumPlugin. Celui-ci est disponible à l’adresse suivante: https://github.com/atoum/sfAtoumPlugin.

15.7.3.1. Installation¶

Il existe plusieurs méthodes d’installation du plugin dans votre projet :

installation via composer
installation via des submodules git

15.7.3.1.1. En utilisant composer¶

Ajouter ceci dans le composer.json :

"require"     : {
  "atoum/sfAtoumPlugin": "*"
},

Après avoir effectué un php composer.phar update, le plugin devrait se trouver dans le dossier plugins et atoum dans un dossier vendor.

Il faut ensuite activer le plugin dans le ProjectConfiguration et indiquer le chemin d’atoum.

<?php
sfConfig::set('sf_atoum_path', dirname(__FILE__) . '/../vendor/atoum/atoum');

if (sfConfig::get('sf_environment') != 'prod')
{
  $this->enablePlugins('sfAtoumPlugin');
}

15.7.3.1.2. En utilisant des submodules git¶

Il faut tout d’abord ajouter atoum en tant que submodule :

$ git submodule add git://github.com/atoum/atoum.git lib/vendor/atoum

Puis ensuite ajouter le sfAtoumPlugin en tant que submodule :

$ git submodule add git://github.com/atoum/sfAtoumPlugin.git plugins/sfAtoumPlugin

Enfin, il faut activer le plugin dans le fichier ProjectConfiguration :

<?php
if (sfConfig::get('sf_environment') != 'prod')
{
  $this->enablePlugins('sfAtoumPlugin');
}

15.7.3.2. Ecrire les tests¶

Les tests doivent inclure le fichier de bootstrap se trouvant dans le plugin :

<?php
require_once __DIR__ . '/../../../../plugins/sfAtoumPlugin/bootstrap/unit.php';

15.7.3.3. Lancer les tests¶

La commande symfony atoum:test est disponible. Les tests peuvent alors se lancer de cette façon :

$ ./symfony atoum:test

Toutes les paramètres d’atoum sont disponibles.

Il est donc, par exemple, possible de passer un fichier de configuration comme ceci :

php symfony atoum:test -c config/atoum/hudson.php

15.7.4. Plugin symfony 1¶

Pour utiliser atoum au sein d’un projet symfony 1, un plug-in existe et est disponible à l’adresse suivante : https://github.com/atoum/sfAtoumPlugin.

Toutes les instructions pour son installation et son utilisation se trouvent dans le cookbook Utilisation avec symfony 1.4 ainsi que sur la page github.

15.7.5. Bundle Symfony 2¶

Pour utiliser atoum au sein d’un projet Symfony 2, le bundle AtoumBundle est disponible.

Toutes les instructions pour son installation et son utilisation se trouvent dans le cookbook Utilisation avec Symfony 2 ainsi que sur la page github.

15.7.6. Composant Zend Framework 2¶

Si vous souhaitez utiliser atoum au sein d’un projet Zend Framework 2, un composant existe et est disponible à l’adresse suivante.

Toutes les instructions pour son installation et son utilisation sont disponibles sur cette page.

15. Cookbook¶

15.1. Changer l’espace de nom par défaut¶

15.2. Test d’un singleton¶

15.3. Hook git¶

15.3.1. Étape 1 : Création du script à exécuter¶

15.3.2. Étape 2 : Ajout des droits d’exécution¶

15.4. Utilisation dans behat¶

15.4.1. Installation¶

15.4.2. Configuration¶

15.4.3. Utilisation¶

15.5. Utilisation dans des outils d’intégration continue (CI)¶

15.5.1. Utilisation dans Jenkins (ou Hudson)¶

15.5.1.1. Étape 1 : Ajout d’un rapport xUnit à la configuration atoum¶

15.5.1.1.1. Si vous n’avez pas de fichier de configuration¶

15.5.1.1.2. Si vous avez déjà un fichier de configuration¶

15.5.1.2. Étape 2 : Tester la configuration¶

15.5.1.3. Étape 3 : Lancement des tests via Jenkins (ou Hudson)¶

15.5.1.4. Étape 4 : Publier le rapport avec Jenkins (ou Hudson)¶

15.5.2. Utilisation avec Travis-ci¶

15.6. Utilisation avec Phing¶

15.6.1. Configuration d’atoum¶

15.6.2. Flags¶

15.6.3. Rapports¶

15.7. Utilisation avec des frameworks¶

15.7.1. Utilisation avec ez Publish¶

15.7.1.1. Étape 1 : Installation d’atoum au sein d’eZ Publish¶

15.7.1.2. Étape 2 : Création de la classe de test de base¶

15.7.1.3. Étape 3 : Création d’une classe de test¶

15.7.1.4. Étapes 4 : Exécution des tests unitaires¶

15.7.2. Utilisation avec Symfony 2¶

15.7.2.1. Étape 1: installation d’atoum¶

15.7.2.2. Étape 2: création de la classe de test¶

15.7.2.3. Étape 3: écriture d’un test¶

15.7.2.4. Étape 4: lancement des tests¶

15.7.3. Utilisation avec symfony 1.4¶

15.7.3.1. Installation¶

15.7.3.1.1. En utilisant composer¶

15.7.3.1.2. En utilisant des submodules git¶

15.7.3.2. Ecrire les tests¶

15.7.3.3. Lancer les tests¶

15.7.4. Plugin symfony 1¶

15.7.5. Bundle Symfony 2¶

15.7.6. Composant Zend Framework 2¶

15.6. Utilisation avec Phing ¶