diff --git a/Documentation/Fr/Index.xyl b/Documentation/Fr/Index.xyl new file mode 100644 index 0000000..56dc9ac --- /dev/null +++ b/Documentation/Fr/Index.xyl @@ -0,0 +1,745 @@ + + + +

Assurer la qualité du logiciel n'est pas facile. La + bibliothèque Hoa\Test fournit plusieurs outils pour écrire et + exécuter des tests, générer des données de tests ou même des tests eux-mêmes + etc. Ceci est la base pour tester les bibliothèques de Hoa. Des articles de + recherche ont été publiés et implémentés dans Hoa\Test et des + bibliothèques connexes (comme Hoa\Praspel, + Hoa\Realdom etc.).

+ +

Table des matières

+ + + +

Introduction

+ +

La qualité logicielle est un sujet très vaste en Informatique. Il y a + beaucoup de stratégies, beaucoup de mesures… et beaucoup de confusion. Une + façon d'assurer la qualité dans Hoa repose sur la stratégie de test. + Commençons ce chapitre par quelques définitions et une présentation des outils + fournis par la bibliothèque Hoa\Test.

+ +

Nature des tests

+ +

Un test est exécuté sur un System Under Test, + abrégé SUT, et est composé de deux parties :

+
    +
  1. les données de test pour exécuter le SUT ; et
    2. +
  2. un oracle, qui établit le + verdict du test : est-ce que les résultats de l'exécution et + l'état du SUT après son exécution sont ceux que nous attendions ou pas ?
    3. +
+

Les valeurs du verdict sont : succès, + échec ou non conclusif. Un succès signifie + que c'est ce que nous attendions, un échec signifie que ce n'est pas ce que nous + attendions et non conclusif signifie qu'il n'est pas possible de donner une réponse. + La partie importante est « ce que nous attendions ». Par + extension, nous comprenons qu'un test n'asserte pas que le SUT est + vérifié.

+
Les tests montrent la présence, non pas l'absence + de bugs.
+

Un test n'assure que la validité du SUT. La différence + est qu'un système valide n'a pas de bug pour quelques exécutions non + exhaustives, tandis qu'un système vérifié fait ce pourquoi il a été + conçu. Bien que les tests ne prouvent pas l'absence de bug, ils sont utiles + (facile à écrire, facile à lire, tous les systèmes ne peuvent être prouvés etc). + Cependant, en fonction des données de test choisies, les tests peuvent être + presque considérés comme des preuves. Par exemple, un test avec des données de + tests exhaustives peut être considéré comme une preuve.

+

Un test peut être écrit manuellement, par exemple par un + ingénieur de test. Un SUT est fourni, l'ingénieur utilise des données de test + pour l'exécuter et le verdict du test est établi par l'ingénieur. Dans le cas + d'un test automatisé, l'exécution du SUT et le verdict du + test sont calculés par la machine. C'est le rôle des frameworks « xUnit » tel + que atoum ou + PHPUnit. L'ingénieur utilisera les frameworks + pour écrire des tests et la machine pour les exécuter. Finalement, les tests + automatiques sont générés et exécutés par la machine. + La machine peut compter sur une spécification, comme un contrat, pour générer + automatiquement les tests (s'il vous plaît, allez voir la + bibliothèque Hoa\Praspel ou + les rapports de recherches que nous avons publiés ci-dessous pour en apprendre + plus sur les paradigmes de Design-by-Contract et + Contact-based Testing). + Les tests automatiques ont deux sous-catégories : les tests + en ligne ou hors-ligne. En ligne signifie + que les tests sont générés et exécutés en une seule passe, tandis que + hors-ligne signifie que les tests sont générés et exécutés plus tard + (avec des données de test ou non).

+ +

Dans Hoa nous avons aussi bien des tests automatisés que + des tests hors-ligne automatiques.

+

Ceci est une classification générale des tests. Une plus précise est décrite + par le schéma ci-dessous qui explique quel type de test écrire :

+
+ +
Dimensions of the test universe is represented by + 3 axis.
+
+

L'axe "Support de conception" décrit la visibilité que nous + avons sur le System Under Test : soit + boite noire ou boite blanche. Leurs + significations sont différentes suivant le contexte mais nous pouvons + considérer un système comme une boite blanche si nous regardons et utilisons + ce qui est dans la boite, sinon + la boite est noire. Par exemple, pour les tests unitaires, disons que le SUT + est une fonction, les tests boite noire vont considérer seulement les entrées + et les sorties de la fonction sans considérer son corps (même si elle lit ou + écrit des variables globales, flux etc.). D'un autre côté, les tests boite + blanche vont considérer le corps de la fonction et la stratégie de test sera + totalement différente. Nous n'attendons pas la même chose d'un système boite + noire ou boite blanche.

+

L'axe "Taille du système" décrit à quel niveau (ou altitude) + nous testons : du plus bas, unitaire (une fonction ou une + méthode) au plus haut, tout le système, ce qui inclut les + composants (ensemble de fonctions) et + l'intégration des composants dans d'autres composants, qui, + ensemble, forment le système. Tous les niveaux sont importants : ce n'est pas + parce qu'une fonction fait ce qu'elle est supposée faire qu'elle s'intégrera + correctement avec une autre.

+ +

Enfin, l'axe "Type de test" décrit l'objectif des tests : + fonctionnel (“tout fonctionne comme prévu et c'est + tout“), robustesse (“il n'est pas possible de mettre + le système dans un état d'erreur si nous faisons quelque chose d'imprévu“), + performance (“le système supporte une forte charge + et se comporte correctement dans ces conditions“) etc.

+

Dans Hoa, nous avons des tests boite blanche et + boite noire, unitaires et + fonctionnels. Nous incluons également des tests de performance + dans certaines bibliothèques.

+

Souvenez-vous que chaque point dans cet univers de tests peut impliquer + différents outils et différentes pratiques de développement. Quand nous parlons + de tests, il est important de garder ce schéma à l'esprit et de situer ou se + trouve notre problématique.

+ +

Test, scénario de test et + suite de test

+ +

Officiellement, un test d'un SUT est un ensemble de données + (appelées données de test) qui alimentent les valeurs des arguments (aussi + appelés entrées) d'un SUT. Un scénario de test est une paire + composée d'un état (le contexte dans lequel est exécuté le test) et un test. + Une suite de test est ensemble de scénario de test. Par + conséquent, il y a deux états du point de vue du test : un + pré-état — avant l'exécution du SUT — et un + post-état — après l'exécution —.

+

Construire le pré-état est critique : le but est de mettre le SUT dans un + (pré-)état spécifique afin de le tester. La partie du scénario de test responsable + de créer le pré-état est appelé le préambule. Ainsi, le + préambler est le code qui met le SUT dans un état spécifique.

+

Ainsi, en écrivant un scénario de test, nous aurons 3 éléments à considérer :

+
    +
  1. Le préambule, pour mettre le SUT dans un état spécifique ;
    2. +
  2. L'exécution, pour exécuter le SUT et obtenir un résultat  ;
    3. +
  3. L'oracle, pour évaluer le verdict (basé sur le résultat + de l'exécution et le post-état).
    4. +
+

L'oracle consiste en une séquence d'assertions : “Est-ce que cette valeur + est égale à… ?”, “Est-ce que la valeur a changé de cette façon… ?” etc. Il + est censé pouvoir vérifier la forme de certaines données mais également + comparer des données entre le pré et le post-état.

+

Dans un scénario de test, nous représentons et introduisons le préambule, + l'exécution et l'oracle respectivement par les mots clés given, + when et then. Ceci sera détaillé ci-après.

+ +

Framework de test

+ +

Hoa n'a pas développé son propre framework de tests pour plusieurs raisons. + La raison principale étant que c'est une tâche laborieuse. Cela implique plus + de développement, plus d'outils à maintenir, moins de gens concentrés sur Hoa + etc. À la place, nous préférons choisir un bon projet sur lequel nous + appuyer et y contribuer. Nous avons opté pour atoum, + “un framework de test simple, moderne et intuitif”.

+

Ainsi, la bibliothèque Hoa\Test est la base pour tester toutes + les bibliothèques de Hoa. Elle intègre atoum et vise à être un pont entre + les fonctionnalités de Hoa et atoum. Elle ajoute également quelques + fonctionnalités si nécessaire. Elle est plus qu'une couche d'abstraction + au-dessus d'atoum. Hoa\Test fournit également sa propre ligne de + commande pour exécuter les tests avec everything pre-packaged. En conséquence, + Hoa\Test fournit un environnement de test prêt à l'emploi pour + Hoa.

+

Il ne faut pas être surpris de voir certains contributeurs de Hoa contribuer + également à atoum. Les deux communautés sont étroitement liées. Hoa fournit + également des contributions officielles à atoum tel que + l'extension + atoum/praspel-extension et d'autres extensions sont basées sur + Hoa, par exemple + l'extension + atoum/ruler-extension qui est basée sur + la bibliothèque Hoa\Ruler, + également utilisée par Hoa\Test. Certaines extensions de atoum + sont même testées avec atoum et Hoa (avec atoum/praspel-extension). + La boucle est bouclée.

+ +

Etudes

+ +

Plusieurs études (articles, journaux et une thèse de + doctorat) ont été publiées à propos de Hoa\Test, + Hoa\Praspel et Hoa\Realdom :

+ +

Ces documents évoquent la génération et de la + validation de données de test, incluant le Design-by-Contract + et le Contract-based-Testing en PHP, ainsi que le Grammar-based Testing et le + Solver-based Testing.

+ +

Ecrire des tests

+ +

Chaque bibliothèque dispose d'un dossier Test/ à la racine de + son dépôt. C'est dans ce dossier que se trouvent les tests. Les tests unitaires + automatisés sont dans le dossier Test/Unit/ tandis que les tests + unitaires générés automatiquement se trouvent dans le dossier + Test/Praspel/Unit/ (pas par défaut, ils doivent d'abord être + générés).

+ +

Tests unitaires automatisés

+ +

Dans Hoa, une suite de test est représentée par un fichier contenant une + classe. Un cas de test est une méthode de cette classe qui exprime le préambule, + l'exécution du SUT et l'oracle. Le modèle d'une suite de test est le suivant + (supposons la suite de test Test/Unit/Bar.php de la bibliothèque + Hoa\Foo) :

+ 
namespace Hoa\Foo\Test\Unit;
+
+use Hoa\Foo\Bar as SUT;
+use Hoa\Test;
+
+class Bar extends Test\Unit\Suite
+{
+    public function case_classic()
+    {
+        // test case.
+    }
+}
+

On définit un alias SUT pour le System Under Test + actuel. Dans le contexte d'un test unitaire, c'est une méthode ou une classe. + On peut également déclarer l'alias CUT, pour Class Under Test, + et LUT pour Library Under Test. LUT + est utile si nous devons accéder à d'autres classes de la même bibliothèque. + Etant donné que ce sont des tests unitaires, nous ne devons pas utiliser d'autres + classes mais rappelez-vous qu'un case de test est composé d'un préambule et + qu'il doit être construit. Dans ce cas, LUT peut être défini comme + Hoa\Foo.

+

La classe Bar étends la classe Hoa\Test\Unit\Suite + qui définit une suite de tests unitaires. Elle offre toute l'API de test + dont on a besoin pour écrire des tests.

+

Les cas de test sont des méthodes publiques. Elles n'utilisent pas la + notation camel case mais une notation underscore lower-cased. + Elles doivent être préfixées par case_. Un cas de test doit + suivre la structure préambule, exécution et oracle, représentés respectivement + par les mots clés given, when et then. + Un cas de test doit donc être écrit de la manière suivant  :

+ 
public function case_classic()
+{
+    $this
+        ->given(
+            …,
+            …,
+            …
+        )
+        ->when(
+            …,
+            $result = …
+        )
+        ->then
+            ->…;
+}
+

Les "structures de contrôle" given et when sont + des appels de fonction avec une arité non-liée. Ce sont des méthodes vides, + elles ne font rien. Le but n'est pas de leur passer quelque chose mais de + déclarer des variables pour établir le préambule et exécuter le test. Par + exemple :

+ 
public function case_sum()
+{
+    $this
+        ->given(
+            $x = 1,
+            $y = 2
+        )
+        ->when(
+            $result = $x + $y
+        )
+        ->then
+            ->integer($result)
+                ->isEqualTo(3);
+}
+

Ceci est strictement équivalent à écrire :

+ 
public function case_sum()
+{
+    // Given:
+    $x = 1;
+    $y = 2;
+    // When:
+    $result = $x + $y;
+    // Then:
+    $this->integer($result)>-isEqualTo(3);
+}
+

Nous utilisons toutefois la première forme qui est plus claire, l'indentation + et les mots clés spéciaux (au travers des noms de méthodes) nous forcent à + séparer clairement les 3 parties : préambule, exécution du test et oracle.

+

La variable $result est spéciale. Elle + doit toujours contenir le résultat de l'exécution du test, + i.e. le résultat de la déclaration return + du SUT. Ceci est une convention.

+

Un cas de test peut contenir plusieurs exécutions avec des oracles multiples + (par exemple si un SUT retourne différent résultats en fonction du temps). + Ainsi, le cas de test doit être écrit comme ceci :

+ 
public function case_classic()
+{
+    $this
+        ->given(…)
+        ->when($result = …)
+        ->then
+            ->…
+
+        ->when($result = …)
+        ->then
+            ->…
+
+        ->when($result = …)
+        ->then
+            ->…;
+}
+

Les assertions sont toujours utilisées après la partie then et + ont la plupart du temps la forme + assertion-groupe->assertion. Nous pouvons + également lier des groupes d'assertions. Par exemple :

+ 
public function case_sum()
+{
+    $this
+        ->given(
+            $x = 1,
+            $y = 2
+        )
+        ->when(
+            $result = $x + $y
+        )
+        ->then
+            ->integer($result)
+                ->isLowerThan(4)
+                ->isGreaterThan(2)
+            ->string((string) $result)
+                ->isNotEmpty();
+}
+

La liste de toutes + les assertions peut être trouvée dans la documentation d'atoum. Même s'il + est naturel d'écrire des assertions car elles sont proches des "conventions + humaines", il est parfois utile de découvrir qu'une assertion spécifique + existe déjà, comme par exemple float->isNearlyEqualTo qui compare + 2 flottants comme prévu la plupart du temps. N'hésitez pas à consulter la + documentation d'atoum régulièrement !

+ +

Génération automatique + des données de test

+ +

Hoa\Test inclut + + l'extension Hoa\Praspel. Cette extension inclut + la bibliothèque Hoa\Praspel + et la bibliothèque Hoa\Realdom + dans atoum. Lors de tests manuels ou automatisés, cette extension peut être + utilisée pour générer automatiquement des données de test.

+

Tout ce que nous avons à faire est de décrire un domaine réaliste (voir la + bibliothèque Hoa\Realdom) avec + l'assertion de groupe realdom et utiliser ensuite l'“assertion” + sample (à l'interne c'est un handler mais la syntaxe est + la même) pour générer une valeur ou sampleMany pour générer + plusieurs valeurs. Par exemple, pour générer automatiquement des entiers dans + l'intervalle 7 à 13 ou 42 à 153 :

+ 
public function case_sum()
+{
+    $this
+        ->given(
+            $_x =
+                $this
+                    ->realdom
+                        ->boundinteger(7, 13)
+                        ->or
+                        ->boundinteger(42, 153),
+            $x = $this->sample($_x)
+        )
+        ->when(…)
+        ->then
+          ->…;
+}
+

Actuellement, atoum/praspel-extension fournit 3 asserters pour + générer des données et 1 asserter pour les valider :

+
    +
  1. realdom pour créer une disjonction de domaine réaliste + (or dans l'exemple précédent),
    2. +
  2. sample pour générer une donnée depuis une disjonction de + domaine réaliste,
    3. +
  3. sampleMany pour générer plusieurs données,
    4. +
  4. predicate pour valider une données en fonction d'une + disjonction de domaine réaliste.
    5. +
+

Hoa\Realdom fournit une collection de domaines réaliste + standards, dont certains très utiles, comme regex qui décrit une + expression régulière (dans le format PCRE). + Ainsi, nous sommes capable de générer automatiquement ou + valider une donnée qui correspond à une expression + régulière. L'exemple suivant génère une chaîne similaire à une + adresse email :

+ 
$this
+    ->given(
+        $email = $this->sample(
+            $this->realdom->regex('/[\w\-_]+(\.[\w\-\_]+)*@\w\.(net|org)/')
+        ),
+        …
+    )
+    ->…
+

L'exemple ci-dessous déclare un domaine réaliste qui représente une date + avec le format d/m H:i, entre hier et lundi prochain :

+ 
$this
+    ->given(
+        $_date = $this->realdom->date(
+            'd/m H:i',
+            $this->realdom->boundinteger(
+                $this->realdom->timestamp('yesterday'),
+                $this->realdom->timestamp('next Monday')
+            )
+        )
+    )
+    ->…
+

Ensuite, pour générer une date :

+ 
$this->sample($_date)
+

Ou pour en générer 42 :

+ 
$this->sampleMany($_date, 42)
+

De la même manière, des booléens, tableaux, classes, couleurs, chaînes basés + sur des grammaires etc. peuvent être générées… mais également validés ! + Contrairement à realdom, sample et + sampleMany, predicate est un vrai asserter. Par + nature, il calcule un booléen : soit true or + false. Il peut être utilisé sur une + disjonction de domaine réaliste, par exemple :

+ 
$this
+    ->given(
+        $_date = $this->realdom->date(
+            'd/m H:i',
+            $this->realdom->boundinteger(
+                $this->realdom->timestamp('yesterday'),
+                $this->realdom->timestamp('next Monday')
+            )
+        ),
+        $stuff = …
+    )
+    ->when($result = SUT::compute($stuff)
+    ->then
+        ->predicate($_date, $result);
+

Dans l'exemple ci-dessus, le domaine réaliste _date est décrit, + non pas pour générer une donnée, mais pour valider le résultat du SUT.

+

Pour obtenir plus d'informations concernant le Grammar-based Testing, voir + la bibliothèque Hoa\Realdom. + Dans tous les cas, veuillez consulter nos études.

+ +

Tests générés + automatiquement

+ +

Cette section a été soutenue par une thèse de doctorat et plusieurs articles de recherches. Cependant, ces outils ne + sont pas encore stable et la documentation est en cours d'écriture. Veuillez + vous référer à la bibliothèque + Hoa\Praspel pour plus d'informations.

+ +

Exécuter les tests

+ +

La plupart du temps, nous exécutons les tests à partir du dépôt de la + bibliothèque. Composer est nécessaire + pour installer ses dépendances, ce qui inclus + Hoa\Test comme une dépendance de développement. Ainsi, à partir + de la racine du dépôt de la bibliothèque :

+ 
$ composer install
+

Par défaut, composer va installer les dépendances de développement. Sinon, + vous pouvez le forcer en ajoutant l'option --dev.

+

Un répertoire vendor/ est ainsi créé. À l'intérieur de ce + répertoire, nous trouvons la commande bin/hoa (veuillez vous + référer à la bibliothèque + Hoa\Cli). Lancer cette commande sans aucune option va lister + toutes les sous-commandes disponible pour cette installation. Nous devrions + voir les commandes de tests. Pour les exécuter, nous allons utiliser la + sous-commande test:run. Nous devons fournir un répertoire où les + tests sont écrits, c'est toujours Test/. Ainsi :

+ 
$ vendor/bin/hoa test:run --directories Test/
+

Notez que l'option --directories a une forme plurielle. C'est + parce que l'on peut spécifier plus d'un répertoire, les noms devant être + séparés par une virgule.

+

À ce stade, nous verrons l'exécution des tests.

+ +

Interprété le résultat du test

+ +

Le rapport de test en ligne de commande utilise des couleurs pour indiquer le + verdicte du test : vert pour un succès, rouge pour un échec ou non + concluant. Dans le cas d'un succès, nous devrions voir :

+ + 
Success (S tests, c/C methods, V void method, K skipped method, A assertions)!
+

où :

+
    +
  • S est le nombre de suite de tests,
    • +
  • c et C sont les nombres de + cas de tests,
    • +
  • V est le nombre de cas de tests non concluant,
    • +
  • K est le nombre de tests skipped,
    • +
  • A est le nombre d'assertions.
    • +
+

Dans le cas d'un échec, nous devrions voir :

+ 
Failure (S tests, c/C methods, V void method, K skipped method, …, F failure, E error, X exception)!
+> There is F failure:
+…
+
    +
  • F est le nombre de cas de tests ayant échoués,
    • +
  • E est le nombre d'erreurs inattendues,
    • +
  • X est le nombre d'exceptions inattendues.
    • +
+

Pour chaque description d'échecs, un “diff” va être calculé, i.e. Une + représentation différentielle textuelle de ce qui est attendue et de ce que + nous avons.

+ +

Mode debug

+ +

Dans certains cas, il est possible que certaines informations de debug + soient accessibles, mais cachées lors d'une exécution des tests classiques. + Pour activer cette sortie, nous devons utiliser l'option + --debug ; Ainsi :

+ 
$ vendor/bin/hoa test:run --directories Test/ --debug
+

L'ordre des options importe peu, comme toujours avec la commande hoa.

+

Pour produire les informations de debug, nous devons utiliser l'instruction dump + lors de l'écriture de notre cas de test. Par exemple :

+ 
public function case_sum()
+{
+    $this
+        ->given(
+            $x = 1,
+            $y = 2
+        )
+        ->when(
+            $result = $x + $y
+        )
+        ->then
+            ->dump($result)
+            ->integer($result)
+                ->isEqualTo(3);
+}
+ +

Sélectionnez les tests à exécuter

+ +

Sélectionnez les tests à exécuter permet un retour rapide + et une plus courte “boucle de test”. Nous avons vu + précédemment l'option --directories pour définir certains + répertoires : Soit le répertoire racine Test, soit un ou plusieurs + sous-répertoire (avec --directories + Test/Foo/,Test/Bar/,Test/Baz/Qux/ par exemple)

+

Nous avons aussi l'option --files pour sélectionner un ou + plusieurs fichiers à exécuter spécifique. Par exemple :

+ 
$ vendor/bin/hoa test:run --files Test/Unit/Foo.php,Test/Unit/Bar.php
+

Finalement, Hoa\Test nécessite l'installation de l'extension + atoum/ruler-extension. Cette extension permet de + filtrer précisément les tests à lancer. Nous y accédons + avec l'option --filter suivie d'une expression. + Anecdote : Les expressions sont basées sur la bibliothèque Hoa\Ruler!

+

Les variables suivantes sont disponibles dans l'expression du filtre :

+
    +
  • method représente le nom du cas de test,
    • +
  • class représente le nom de la suite de test,
    • +
  • namespace représente l'espace de nom de la suite de test,
    • +
  • tags représente la suite de test ou le label du cas de test.
    • +
+

Tous les opérateurs standards de la bibliothèque Hoa\Ruler + peuvent être utilisés. Par exemple, pour lancer uniquement la suite de test + Hoa\Foo\Test\Unit\Bar qui est représentée par une classe, nous + écrirons :

+ 
$ vendor/bin/hoa test:run --directories Test/ --filter 'class = "Hoa\Foo\Test\Unit\Bar"'
+

Ou, pour lancer uniquement deux cas de tests spécifiques, supposons + case_sum et case_baz :

+ 
$ vendor/bin/hoa test:run --directories Test/ --filter 'method = "case_sum" or method = "case_baz"'
+

L'exemple précédent est strictement équivalent à :

+ 
$ vendor/bin/hoa test:run --directories Test/ --filter 'method in ["case_sum", "case_baz"]'
+

Un autre exemple de filtre pour les suites de tests : Seulement ceux terminant par + Qux :

+ 
$ vendor/bin/hoa test:run --directories Test/ --filter 'class matches "Qux$"'
+

L'opérateur matches nécessite une expression régulière respectant + le format PCRE.

+

Finalement, les cas de tests et les suites de tests peuvent avoir un ou plusieurs labels, merci à l'annotation + @tags. Une annotation est un commentaire du genre /** + … */ localisé au-dessus d'une classe, interface, méthode, + fonction etc. Les labels permettent d'avoir une classification des cas de + tests. Par exemple :

+ 
/**
+ * @tags featureA featureB
+ */
+public function case_sum()
+{
+    // …
+}
+

Pour lancer uniquement les cas de tests avec le label featureA, + nous allons utiliser la ligne de commande suivante :

+ 
$ vendor/bin/hoa test:run --directories Test/ --filter '"featureA" in tags'
+

Ici, la variable tags contient un tableau de chaines + représentant les noms des labels.

+ +

Choisir la machine + virtuelle PHP

+ +

Lors de test, il est aussi utile de pouvoir choisir une machine + virtuelle PHP spécifique, comme une + version spécifique de PHP (la machine virtuelle par défaut) ou + la dernière version de HHVM par exemple. Il y + a plusieurs machine virtuelle PHP de nos jours et nous ne pouvons les + ignorer.

+

Nous choisissons la machine virtuelle en utilisant l'option + --php-binary et e fournissant le chemin vers le binaire ; + par exemple:

+ 
$ vendor/bin/hoa test:run --directories … --php-binary /usr/bin/php
+

Nous pouvons imaginer la valeur de l'option --php-binary + définie par une variable globale. Ainsi, nous pouvons réutiliser le même + script pour exécuter les tests avec plusieurs machines virtuelles, comme :

+ 
$ PHP_BIN=/usr/bin/php vendor/bin/hoa test:run --directories … --php-binary $PHP_BIN
+

Il est conseillé d'utiliser le plus possible la syntaxe PHP et les + fonctionnalités décrites dans les spécifications PHP

+ +

Moteur d'exécution des tests

+ +

atoum fournit plusieurs moteurs d'exécution de test, tels que :

+
    +
  • Inline, un cas de test après un autre dans le même + processus,
    • +
  • Isolate, un cas de test après un autre, mais à chaque fois + dans un nouveau processus,
    • +
  • Concurrent, “tous” les cas de tests en même temps dans des + processus séparés.
    • +
+

Lorsque nous exécutons les tests, l'isolation est vraiment importante : + Pas de conflit de mémoire, pas de conflit d'exécution, l'état du SUT est + réinitialisé à chaque fois etc. + Le verdict du test ne dépend pas de l'exécution précédente et par conséquent + déterministe et non ambigu (seulement si le + SUT l'est).

+

Par defaut, Hoa\Test va utiliser le moteur d'exécution de + test concurrent. Tous les cas de tests ne snt pas exécuté au + même moment ; en fait, le nombre de cas de tests à exécuter sont définis par + le nombre de processus utilisés. Par defaut, c'est soit 2 ou 4 dépendant de + la platforme, mais nous pouvons le spécifier avec l'option + --concurrent-processes. + Ainsi, pour forcer l'utilisation de 1024 processus pour lancer les tests + (supposant que nous ayons un serveur monstre) :

+ 
$ vendor/bin/hoa test:run --directories Test/ --concurrent-processes 1024
+

Parce que les tests inline ne sont pas intéressants pour + les cas de tests et le contexte de Hoa et parce que l'isolation du moteur + d'exécution des tests a plus de contre que de pour comparer au mode concurrent + (principalement ce dernier est plus rapide que le premier), nous ne pouvons + changer le moteur d'exécution des tests. Cependant, pour simuler le moteur + d'exécution isolé, nous pouvons forcer --concurrent-processes à + 1.

+ +

Virtual file system

+ +

The Hoa\Test library provides a virtual file system over its + hoa:// protocol to ease testing of files or directories.

+

The root of the virtual file system is + hoa://Test/Vfs/. Everything added after this root will be a path + to a virtual file or a directory. + Additional query strings can be present to specify more + information, such as permissions, access time etc. The parent-child relation + is automatically created, not need to specify that a file is a child of a + directory, this is deduced from the path.

+

Note: The virtual file system is only accessible from inside a test + case.

+ +

Files or directories

+ +

A virtual file Foo can be represented by the following path: + hoa://Test/Vfs/Foo. In this case, either we open it with + regular stream functions like + fopen, + fread, + fwrite, + file_put_content + etc. or, with the Hoa\File + library, thus:

+ 
$file = new Hoa\File\ReadWrite('hoa://Test/Vfs/Foo');
+$file->writeAll('Hello world!');
+
+var_dump($file->readAll());
+
+/**
+ * Will output:
+ *     string(12) "Hello world!"
+ */
+

To create a directory, we must specify a stream type by using the + type query string; thus:

+ 
$directory = new Hoa\File\Directory('hoa://Test/Vfs/Foo?type=directory');
+

This is due to the fact that we cannot deduce stream type based on its + name. By default, type=file is implied.

+

For the rest, it works like any regular files or directories, nothing + different.

+ +

Permissions

+ +

Pour modifier les permissions, les fonctions d'autorisation de flux + spécifiques peuvent être utilisées ou nous pouvons les définir directement en + utilisant la chaîne de requête de permissions suivie d'une valeur octale ; + Ainsi :

+ 
$file = new Hoa\File\ReadWrite('hoa://Test/Vfs/Foo?permissions=0644');
+var_dump($file->getReadablePermissions());
+
+/**
+ * Will output:
+ *     string(10) "-rw-r--r--"
+ */
+

Comme toutes requêtes, nous pouvons concaténer des clefs-valeurs en + utilisant le symbole &. Par exemple, + type=directory&permissions=0644 représente un + répertoire avec les autorisations 0644.

+ +

Access-, change- and + modify-time

+ +

This can also be useful to define access-, change- and modify-time by + respectively using the atime, ctime and + mtime query strings. The expected values are an integer + representing a timestamp (a number of seconds). Thus, to represent a file + that has been accessed in the future (in 1 minute):

+
$aTime = time() + 60;
+$file  = new Hoa\File\ReadWrite('hoa://Test/Vfs/Foo?atime=' . $aTime);
+ +

Conclusion

+ +

La bibliothèque Hoa\Test est un ensemble d'outils permettant + de réaliser des tests unitaires ou + fonctionnels, automatisés ou + automatiques, soit en boîtes blanches, soit + en boîtes noires. Elle est plus qu'un wrapper autour d'atoum : Elle fournit une structure de test et de + conventions, un système de fichiers virtuel et des + extensions pour générer automatiquement des + données de test, générer automatiquement des tests ou d'obtenir un puissant + système de filtrage de test. Tests basés sur la grammaire, + tests basés sur le solveur, tests basés sur des résultats aléatoires, tests + basés sur des contrats… tous ces paradigmes se trouvent dans + Hoa\Test. Plusieurs articles de + recherche ont été publiés dans des publications et des conférences + importantes sur les tests.

+ + +