"2- Il y a un concept à bien prendre en compte, les tests viennent "se
placer par dessus l'application" :
Si le code de ton appli est correct, tu ne dois pas le modifier pour
faire fonctionner les tests. "

>>> Entièrement d'accord, c'est pour cela que je m'interroge.


"Donc lors du bake, il ne faut pas utiliser la config test, on fait un
bake de l'appli comme elle le sera en production. Bake va seulement
rajouter les fichiers pour créer les tests unitaire. Et Ô grand jamais
on ne modifie
le code de l'application pour le tester. "

>>> Voilà la seule réponse que j'attendais !

"on spécifie
$useDbConfig = 'test' seulement dans les fichiers de tests comme dans
les examples de euphrate et moi-même. "

>>> Ben oui, mais avec la script Bake on ne peut pas faire çà ! Les fichiers de 
>>> tests sont générés automagiquement et si tu as dis "default" et bien les 
>>> fichiers de tests créés ne contiennent pas "$UseDbConfig = 'test' "...


"L'interêt des tests unitaires est d'autoriser un "développement
agile" : Lorsque tu implémente une nouvelle fonctionnalité dans ton
appli tu as des chances de casser une des fonctionnalités précedemment
integré, tu ne vas pas à chaque fois tout retester au risque d'en
oublier. C'est là qu'on utilise la suite de tests. Une sorte de cahier
de recettage automatisé. "

>>> Même si je suis débutant avec les test unitaires, je connais bien ce 
>>> principe et je ne cherche pas à faire autre chose...


"J'indique aussi "Cette base est accéssible et vide !", cela signifie
que la base de données et présente dans mysql et qu'elle est vide!
Aucun schema ne doit être importé. test suite va recreer un
environnement de test tout seul."

>>> OK, c'est ce que j'avais compris, mais là encore Bake n'aime pas, 
>>> apparemment, que la base soit vide... je reteste !


Remarque 3 : OK, mais comme moi je ne créé pas mes tests tout seul
pour le moment, je me dis que logiquement les variables générées par
Bake respectent les conventions !

Remarque 4 : je reteste, mais je suis presque sûr que la table n'est
pas créée par le lancement du test unitaire


PS : oui je sais que nous avons souvent des échanges sur le fait que
la 1.2 est encore une bêta et qu'il ne faut pas lui demander la lune,
mais j'essaie de comprendre si les difficultés viennent de moi ou de
Cake ! Et comme je ne suis pas un dieu en anglais, j'ai parfois du mal
à communiquer directement sur le Group Anglais ou à déposer des
tickets sur le Trac...
En tout cas, merci à vous deux pour votre disponibilité ! Je refais
des tests et vous tiens au courant.



On 15 fév, 13:16, esion <[EMAIL PROTECTED]> wrote:
> Ok donc :
> 1- J'ai bien dis "test suite" fait presque tout, tout seul (et pas le
> shell bake), mais je suis d'accord que c'est loin d'être parfait et
> surtout ce n'est pas du tout intuitif.
>
> 2- Il y a un concept à bien prendre en compte, les tests viennent "se
> placer par dessus l'application" :
> Si le code de ton appli est correct, tu ne dois pas le modifier pour
> faire fonctionner les tests.
> L'interêt des tests unitaires est d'autoriser un "développement
> agile" : Lorsque tu implémente une nouvelle fonctionnalité dans ton
> appli tu as des chances de casser une des fonctionnalités précedemment
> integré, tu ne vas pas à chaque fois tout retester au risque d'en
> oublier. C'est là qu'on utilise la suite de tests. Une sorte de cahier
> de recettage automatisé.
> Donc lors du bake, il ne faut pas utiliser la config test, on fait un
> bake de l'appli comme elle le sera en production. Bake va seulement
> rajouter les fichiers pour créer les tests unitaire. On spécifie
> $useDbConfig = 'test' seulement dans les fichiers de tests comme dans
> les examples de euphrate et moi-même. Et Ô grand jamais on ne modifie
> le code de l'application pour le tester.
>
> J'indique aussi "Cette base est accéssible et vide !", cela signifie
> que la base de données et présente dans mysql et qu'elle est vide!
> Aucun schema ne doit être importé. test suite va recreer un
> environnement de test tout seul. Dans le principe on pourrait même ne
> pas utiliser cette base de test voilà un exemple des requetes généré
> automatiquement par test suite :
>
> CREATE TABLE `test_suite_users` ( `id` int(10) NOT NULL
> AUTO_INCREMENT, `username` varchar(40) NOT NULL, `password`
> varchar(40) NOT NULL, `email` varchar(255) NOT NULL, `created`
> datetime NOT NULL, `modified` datetime NOT NULL, PRIMARY KEY (`id`) );
> TRUNCATE TABLE `test_suite_users`
> INSERT INTO `test_suite_users`(`id`,`username`,`password`,`email`)
> VALUES
> (1,'admin','4308fb05a903a6c0add7534f3f73bee25ec16f3d','[EMAIL PROTECTED]')  ;
> TRUNCATE TABLE `test_suite_users`
> DROP TABLE IF EXISTS `test_suite_users`;
>
> Je n'ai rien importé comme schéma, c'est test suite qui s'en occupe.
>
> 3- Je ne parlais pas des convention de nommage de tes tables/modèles/
> controller mais des noms de variables/méthodes utilsés dans les tests.
> On a par exemple des résultats de conception différents entre les
> exemples d'euphrate et moi si par malheur on les mélanges, il y a de
> grandes chances que les tests ne fonctionnent plus.
>
> 4- Si :p
>
> PS : on a déjà eu cette conversation au sujet de bake/cake1.2.
> Cake 1.2 est en version beta, si on l'utilise on prend le risque de
> rencontrer des bugs ou des fonctionnalités à moitié implémenté et il y
> en a beaucoup (bake en fait partie). C'est pour cette raison que l'on
> utilise cake1.1 là où je travaille. C'est un choix difficile surtout
> quand on voit tous ce que nous apporte la 1.2
>
> On 15 fév, 11:26, avairet <[EMAIL PROTECTED]> wrote:
>
> > Bravo à vous deux pour cette plongée dans les test unitaires, mais
> > vous êtes allés bien plus loin que moi et vos exemples dépassent de
> > loin mes interrogations !
>
> > @esion :
>
> > 1) tu dis "En fait, il n'y a pas à s'embêter : le testsuite de cake
> > fait presque
> > tout, tout seul."
>
> > >>> Ben non, justement, le test suite ne fait pas tout tout seul... ou 
> > >>> plutôt il le fait mal !
>
> > 2) "tu spécifies seulement que tu veux utiliser la base de données de
> > test : $useDbConfig = 'test'
> > Cette base est accéssible et vide !"
>
> > >>> Je suis désolé, mais si je précise "$useDbConfig" dans mes modèles, je 
> > >>> vais bien devoir y repasser pour le supprimer lorsque je voudrais 
> > >>> utiliser ma base par défaut ! Or le script Bake écrit bien cela dans 
> > >>> tous les modèles, quand on lui dit d'utiliser "test" comme DbConfig...
>
> > 3) "Si tu obtiens un message d'erreur ("xyz_test n'existe pas") c'est
> > seulement un problème de convention de nommage, test suite est très
> > pointilleux et l'exemple du bakery n'a pas l'air de fonctionner tel
> > quel. "
>
> > >>> toutes mes tables respectent la convention de nommage et comme je fais 
> > >>> générer mes modèles et contrôleurs de base par le script Bake, ils 
> > >>> respectent eux aussi les conventions...
>
> > 4) Lorsque user.test.php est lancé
> > 1- la classe UserTestCase est chargée
> > 2- fixtures est spécifié : la table `test_suite_users` est créée dans
> > la base de test (automagiquement, enfin je pense)
>
> > >>> Et ben non, justement, la table n'est pas créée automagiquement si la 
> > >>> base test ne contient rien au départ !
>
> > Je précise que mes fichiers de tests sont ceux générés par le script
> > Bake...
>
> > On 15 fév, 10:58, esion <[EMAIL PROTECTED]> wrote:
>
> > > Okay,
> > > Si je peux me permettre, dans ce cas tu peux aussi définir un nouveau
> > > test pour avoir plus de précision sur l'origine d'une erreur :
>
> > > [...]
> > > function validTest(){
> > >       $result = true;
> > >       $this->assertTrue($result);
>
> > > }
>
> > > function invalidTest(){
> > >      $result = true;
> > >      $this->assertFalse($result);}
>
> > > [...]
>
> > > Le message d'erreur est le suivant :
> > > Fail:[...]user.test.php -> UserTestCase -> invalidTest -> Expected
> > > false, got [Boolean: true] at [[...]user.test.php line 58]
>
> > > Je viens d'essayer un autre aspect de testsuite qui conviendrait aux
> > > tests de scénario. Dans nos exemples on avait un résultat du type
> > > 1/1 test cases complete: 5 passes, 0 fails and 0 exceptions.
> > > Ce qui signifie que les 5 méthodes du cas de test présent sont
> > > valides.
>
> > > On pourrait alors rajouter des cas de tests, mais ça n'a pas l'air de
> > > fonctionner.
> > > J'ai essayé quelque chose comme ça :
>
> > > //file : user.test.php
> > >  App::import('Model', 'User');
>
> > > class UserTest extends User {
>
> > >         var $name = 'User'; //Définition des objets avec le nom
> > > d'origine
> > >         var $useDbConfig = 'test'; //Spécification de la base de
> > > données à
> > > utiliser
>
> > > }
>
> > > class TestACase extends CakeTestCase {
> > >         var $fixtures = array('user');
>
> > >         function startCase(){
> > >                  $this->TestObject = new UserTest();
> > >         }
> > >         function endCase(){
> > >                  unset($this->TestObject();
> > >         }
>
> > >         function validTest() {
> > >                  $this->assetTrue(true);
> > >         }
>
> > > }
>
> > > class TestBCase extends CakeTestCase {
> > >         var $fixtures = array('user');
>
> > >         function startCase(){
> > >                  $this->TestObject = new UserTest();
> > >         }
> > >         function endCase(){
> > >                  unset($this->TestObject();
> > >         }
>
> > >         function invalidTest() {
> > >                  $this->assetTrue(false);
> > >         }
>
> > > }
>
> > > Le résultat :
> > > 2/2 test cases complete: 1 passes, 0 fails and 0 exceptions.
> > > En principe, il devrait y avoir "1 fails".
>
> > > On Feb 15, 9:48 am, euphrate_ylb <[EMAIL PROTECTED]> wrote:
>
> > > > Je voulais avoir un test raté et un qui fonctionne. Donc de ce point
> > > > de vue, ca marche parfaitement.
>
> > > > Pour le useTable je pense que ca vient effectivement de la facon de
> > > > faire l import (import des données). De nombreuses personnes utilisant
> > > > la meme methode ont eu le meme probleme que le mien.
>
> > > > esion wrote:
> > > > > function testMe() {
> > > > >                 $result = $this->TestObject->findAll();
> > > > >                 debug($result);
> > > > >                 $expected = 1;
> > > > >                 $this->assertEqual($result, $expected);
> > > > >                 [...]
> > > > > �a je vois pas trop comment �a peut fonctionner sur un findAll. 
> > > > > Serait-
> > > > > ce un oubli?
>
> > > > > Je n'ai pas eu besoin de sp�cifier $useTable, la requ�te execut� :
> > > > > SELECT `User`.`id`, `User`.`username` FROM `test_suite_users` AS
> > > > > `User` WHERE 1 = 1
>
> > > > > Est-ce que c'est d� � tes fixtures et essentiellement la ligne
> > > > > import :
> > > > >   var $import = 'array('table' => 'users', 'records' => true);
> > > > > ?
>
> > > > > On Feb 14, 11:59 pm, euphrate_ylb <[EMAIL PROTECTED]> wrote:
> > > > > > Pour faire marcher ce test simple, j'ai principalement du lutter 
> > > > > > pour
> > > > > > trouver les deux astuces suivantes:
> > > > > > 1.  d�finir dans UserTest l'attribut useTable (sinon il cherche la
> > > > > > table users et pas user_tests)
> > > > > > 2. ne pas utiliser setUp et TearDown mais preferer startCase()
> > > > > > endCase()
>
> > > > > > Bref merci bake pour ton travail a moitie fonctionnel!!
>
> > > > > > Ce qui donne :
>
> > > > > > // File fixture
> > > > > > class UserTestFixture extends CakeTestFixture {
> > > > > >     var $name = 'UserTest';
> > > > > >     var $import = 'array('table' => 'users', 'records' => true);
>
> > > > > > }
>
> > > > > > // File test
> > > > > > class UserTest extends User {
> > > > > >     var $name = 'UserTest';
> > > > > >     var $useDbConfig = 'test_suite';
>
> > > > > >     var $useTable = 'user_tests';
>
> > > > > > }
>
> > > > > > class UserTestCase extends CakeTestCase {
> > > > > >         var $TestObject = null;
>
> > > > > >         var $fixtures = array( 'user_test' );
>
> > > > > >         function startCase() {
> > > > > >                 $this->TestObject = new UserTest();
> > > > > >         }
>
> > > > > >         function endCase() {
> > > > > >                 unset($this->TestObject);
> > > > > >         }
>
> > > > > >         function testMe() {
> > > > > >                 $result = $this->TestObject->findAll();
> > > > > >                 debug($result);
> > > > > >                 $expected = 1;
> > > > > >                 $this->assertEqual($result, $expected);
>
> > > > > >                 $this->assertTrue($this->TestObject->save(
> > > > > >                         array(
> > > > > >                                 'UserTest' => array(
>
> ...
>
> plus de détails »
--~--~---------~--~----~------------~-------~--~----~

Groupe "Cakephp-fr".
Adresse : [email protected]
Pour résilier  : [EMAIL PROTECTED]
Pour les options : http://groups.google.com/group/cakephp-fr?hl=fr
-~----------~----~----~----~------~----~------~--~---

Répondre à