Oh que oui, on en deviendrait végétarien :]

Je commence à entrevoir la puissance du concombre ;)

Je te post ça dès que j’ai fini.

Pour continuer donc :

Les Users Stories, les scenarii en fait qui composent ton application, t’aident à savoir de quelles méthodes (actions) et de quelles variables tu vas avoir besoin dans tes classes…

Mais est-ce que cela peut également t’aider à savoir de quelles classes tu vas avoir besoin finalement ?
Je suppose que oui !

Déjà, ce qui met tout le monde d’accord est ce qu’il ne faut *pas* tester : il ne faut pas tester du code qui n’est pas écrit par toi. Donc, on ne test pas qu’un controller appelle la bonne méthode, on ne test pas qu’une association fonctionne bien, etc. C’est aux tests du core de rails de s’occuper de ça.

Ensuite, il devient plus clair de savoir quoi tester à partir du moment où tu écris tes tests avant d’écrire ton code. Décrit simplement dans ton test ce que tu veux que ton code fasse. Si par exemple tu as une méthode de modèle appelée fullname qui doit rassembler les entrées firstname et lastname en ajoutant un préfix de titre au début qui sera passé en argument (ex: “Monseigneur Jean Dupont”, désolé pour l’exemple :P ), tu écriras un test avant d’écrire cette méthode qui dira que ton modèle, lorsqu’on appelle cette méthode, doit recevoir l’argument “Monseigneur”, doit appeler “firstname” et “lastname” et doit répondre “Monseigneur Jean Dupont”.

Les partisans du full test coverage te diront aussi que tu dois écrire un test qui vérifie qu’il n’est pas possible d’appeler la méthode sans arguments, qu’une erreur doit être générée si l’instance du modèle n’a pas d’attribut firstname défini, etc.

Pour ma part, je trouve plus naturel de développer “à l’envers”. Plutôt que de penser le schémas de ma base de donnée en essayant de me représenter tout ce dont j’ai besoin, puis faire des tests de modèles en poussant ma réflexion pour deviner quelle méthodes il doivent avoir, et donc quels tests faire, je procède ainsi :

1°) je fais valider mes users stories d’une fonctionnalité. Chaque scénario test une action précise.

2°) je prend le scénario d’une action, et j’écris la vue qui y correspond. Le scénario cucumber étant son test, je sais précisément ce que doit être ma vue.

3°) Ayant écrit la vue, je sais quels variables doivent y être assignées. Je peux donc écrire mon test de controller pour cette action et je test que tout est assigné comme il le faut.

4°) Sachant précisément ce qui doit être assigné, je peux écrire l’action de mon controller. Comme dans le cas de la vue, le simple fait de l’écrire me fait savoir ce dont on besoin mes modèles.

5°) Je peux donc maintenant écrire les tests de mes modèles. Je sais de quel modèle j’ai besoin, quelles méthodes ils doivent avoir avec quels paramètres et quelle valeur de retour.

6°) j’écris ces modèles. Je sais désormais quel schémas de db je dois avoir à ce moment.

7°) je recommence à 2°) jusqu’à ce que j’ai épuisé mes scénarii et que tous les tests passent. Puis j’écris l’user story d’une autre fonctionnalité.

Cette méthodologie me permet de savoir précisément quoi tester. Maintenant, comme je te disais, elle est très personnelle :)

Si je devais me risquer à formuler une règle universelle sur quoi tester, je dirais que tu dois tester le comportement de tes classes, en écrivant ce que tu te représente au moment où tu la conçois. Ma classe doit avoir telle méthode qui retourne ceci en faisant cela. Test que ceci est retourné, et que cela a été appelé.

Cucumber est le story runner de RSpec (bien qu’il puisse être utilisé sans). En gros, dans le tercet unit/functional/integration, il s’occupe des test d’intégration. Il risque donc de ne pas te suffire :)

Il a cependant un avantage énorme sur les autres : il peut être utilisé hors-ruby. Je m’en sers personnellement, couplé avec phpspec, pour tester mes sites php.

Enfin, cucumber va un peu plus loin que du TDD : son auteur le qualifie d’outil de “user acceptance driven development”. Je test ça en conditions réelles dans mes contrats, ca marche pas mal. Tu écris des user stories, tu les fais valider par tes clients et ça devient des tests. Ça change radicalement la façon de développer, même quand on s’est fait au TDD :)