Discussion :

[bilbonec]

Bonjour,

J'ai réalisé quelques tests unitaires, dans 4 fichiers différents.
Afin de savoir si une modif n'avait pas entraîné de régression dans mon code, je lance : php symfony test:unit
J'obtiens un résultat rassurant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
C:\***>php symfony test:unit
cityTableTest........................................................ok
notificationReportFormTest...........................................ok
simpleStatsTableTest.................................................ok
simpleStatsTest......................................................ok
 All tests successful.
 Files=4, Tests=15

Cependant, derrière ça je lance :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
php symfony test:unit cityTable
[...]
# Looks like you failed 3 tests of 8.

Y a-t-il un bug connu avec la commande test:unit ?
Dois-je donc tester tous mes fichiers séparément ?

[Michel Rotta]

Est-ce qu'un autre de tes tests ne changerait pas les conditions du test qui échoue seul, le rendant compatible avec la série, mais pas solitaire ?

[bilbonec]

Je n'ai pas très bien compris ta question, mais je viens de trouver la solution :

Dans mon fichier cityTableTest.php, je possède deux "suites" (pas au sens de PHPUnit) de tests :
- une pour tester que mes initialisations d'objets se déroulent correctement (objets nécessaires à mes tests) ;
- une pour mes tests de méthodes eux-mêmes.

Les deux sont déclarées au moyen de :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$t = new lime_test(n)

La première suite de tests passe.
La seconde échoue.

En déclarant qu'une seule fois dans le fichier : $t = new lime_test(n+m), j'obtiens bien le résultat attendu :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
C:\***>php symfony test:unit
cityTableTest........................................................not ok
    Failed tests: 8
notificationReportFormTest...........................................ok
simpleStatsTableTest.................................................ok
simpleStatsTest......................................................ok
Failed Test                     Stat  Total   Fail  Errors  List of Failed
--------------------------------------------------------------------------
cityTableTest                      0     14      1      0  8
Failed 1/4 test scripts, 75.00% okay. 1/23 subtests failed, 95.65% okay.

Il semblerait donc que la commande :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

php symfony test:unit

ne gère pas le fait qu'il puisse y avoir plusieurs suites de tests dans un même fichier.

[Michel Rotta]

C'est bien possible, dans les exemples il n'y a qu'une instance, hasard ou volonté ?

Ma "question" ou plutôt "proposition d'explication" était que l'exécution de ton fichier de test se basait sur des données modifiées par un autre fichier de test. Donc il était juste dans l'ensemble des tests, mais faux pris indépendamment (ça m'est arrivé dans mes premiers fichiers de test...)

[bilbonec]

Ah ok, j'ai compris. Donc non, ce n'était pas ça : je fais toujours un rollback à la fin de chaque fichier de test. Du coup ça m'assure un comportement cohérent à chaque fois que je lance un fichier. Mais c'est une remarque qui aurait pu se révéler très pertinente !

Et sinon oui, j'aurais peut-être dû en mettre plus dans mon premier exemple. J'ai voulu ne laisser que ce qu'il semblait utile, mais c'était de la forme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
php symfony test:unit cityTable
[...]
# Looks like everything went fine.
# Looks like you failed 3 tests of 8.

[Michel Rotta]

Ah ok, j'ai compris. Donc non, ce n'était pas ça : je fais toujours un rollback à la fin de chaque fichier de test. Du coup ça m'assure un comportement cohérent à chaque fois que je lance un fichier.

Personnellement, je fais le rollback en début de fichier pour que l'état de la base soit toujours conforme pour mon test, même si le précédant aurait complétement planté, empêchant la remise en place de la base...

[bilbonec]

Pas idiot ! Par contre, comment mets-tu cette idée en place ?

Personnellement, en début de fichier j'ai :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
<?php
 
include(dirname(__FILE__).'/../bootstrap/Doctrine.php');
 
// Tables
$userTable = Doctrine_Core::getTable('sfGuardUser', $configuration);
 
// Connection
$conn = $userTable->getConnection();
$conn->beginTransaction();
 
[...]

Tu aurais donc :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
<?php
 
include(dirname(__FILE__).'/../bootstrap/Doctrine.php');
 
// Tables
$userTable = Doctrine_Core::getTable('sfGuardUser', $configuration);
 
// Connection
$conn = $userTable->getConnection();
$conn->rollback();
$conn->beginTransaction();
 
[...]

?

Pour le premier fichier lancé, vu qu'il n'y a pas de transaction d'ouverte auparavant, n'est-ce pas problématique d'avoir un rollback ?

[Michel Rotta]

Non, pas du tout, je me sert du code donnés dans le tutoriel jobeet qui permet de vider la base et de la recharger à partir des fixtures.

Ce qui permet de tester des fonctions qui incluent un rollback, au cas où.

Et, voir, dans certains fichiers de test, éventuellement, de réinitialiser la base après un test destructif (ou potentiellement destructif).