À propos de $useDBconfig, je disais
"Dans le principe on pourrait même ne
pas utiliser cette base de test "
Je pense que c'est normal que bake ne le spécifie pas. Les tests
créent ses propres tables (test_suite_users) du coup ça n'entraverait
pas celles de l'appli.
/me content d'avoir pu faire partie de la solution.
On 15 fév, 13:46, avairet <[EMAIL PROTECTED]> wrote:
> "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".
>
> ...
>
> 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
-~----------~----~----~----~------~----~------~--~---
