Yii Framework Official Guide Series 38 - Définition d'états spécifiques (luminaires)

Les tests automatisés doivent être exécutés plusieurs fois afin de garantir que le processus de test est reproductible, nous voulons vraiment tester dans certains états connus. , nous appelons cet état État spécifique Par exemple, lors du test de la fonctionnalité de création d'article dans une application de blog, à chaque fois que nous effectuons le test, le tableau lié à l'article (par exemple. Post tableau , Comment table) doit être restaurée dans un état spécifique. La documentation PHPUnit contient une bonne description de la construction générale d'un état spécifique. Cette section présente principalement comment construire un état spécifique à une base de données comme l'exemple qui vient d'être décrit.

La définition de l'état spécifique de la base de données construite est probablement l'une des parties les plus chronophages du test des applications avec prise en charge du backend de base de données. Le composant d'application CBbFixtureManager introduit par Yii peut efficacement atténuer ce problème lors de la réalisation d'un ensemble de tests. fait essentiellement ce qui suit :

• Avant que tous les tests ne soient exécutés, il réinitialise les données liées aux tests à un état connaissable

• Avant un seul. test est exécuté, il réinitialise une table spécifique à un état connu

• Lors de l'exécution d'une méthode de test, il fournit un moyen de fournir des données de ligne pour un état spécifique.

Veuillez utiliser le CDbFixtureManager que nous avons configuré dans la configuration de l'application comme suit.

return array(
    'components'=>array(
        'fixture'=>array(
            'class'=>'system.test.CDbFixtureManager',
        ),
    ),
);

Ensuite, nous fournissons des données d'état spécifiques sous le répertoire protected/tests/fixtures Ce répertoire peut être spécifié comme un autre répertoire en configurant l'attribut CDbFixtureManager::basePath dans le fichier de configuration de l'application. Les données d'état spécifiques sont composées de plusieurs noms. une combinaison de fichiers PHP de fichiers d'état spécifiques. Chaque fichier d'état spécifique renvoie un tableau, représentant la ligne initiale d'une table de données spécifique. Le nom du fichier et le nom de la table sont les mêmes. 🎜> table Exemple dans un fichier nommé Post.Post.php

<?php
return array(
    &#39;sample1&#39;=>array(
        'title'=>'test post 1',
        'content'=>'test post content 1',
        'createTime'=>1230952187,
        'authorId'=>1,
    ),
    'sample2'=>array(
        'title'=>'test post 2',
        'content'=>'test post content 2',
        'createTime'=>1230952287,
        'authorId'=>1,
    ),
);

alias de ligne (par exemple : , simple1). Plus tard, lorsque nous écrirons le script de test, nous pourrons facilement appeler cette ligne de données via son alias. Nous présenterons cela en détail dans la section suivante simple2

dans l'état spécifique ci-dessus. En effet, le champ id a été défini comme une clé primaire à incrémentation automatique, et sa valeur sera également automatiquement générée lorsque nous insérons de nouvelles données. .id

. Lorsque CDbFixtureManager détecte cela. Si le script existe, il exécutera ce script au lieu de réinitialiser chaque table.init.php

. Le fichier de script d'initialisation de la table .init.php est Post. Lorsque CDbFixtureManager trouve ce script, il exécutera ce script au lieu d'utiliser la méthode par défaut pour réinitialiser la table.Post.init.php

Conseil : Trop de fichiers spécifiques à un état prolongent considérablement la durée du test. Par conséquent, vous ne devez fournir que des fichiers d'état spécifiques pour les tables dont les données changeront pendant le test. Les tables qui servent de services de recherche ne changeront pas et ne nécessitent donc pas d'état spécifique. fichiers.