ATDD à double boucle: automatiser un test d'acceptation (ATQC17 - 90 minutes)

/ Édition 90 minutes

Imaginez que vous adoptez le BDD et avez des scénarios Gherkin à automatiser… Vous ne savez pas trop comment vous y prendre et ça fait beaucoup de tests bout-en-bout difficiles à maintenir...

Comment faire techniquement pour partir du scénario et l'automatiser?
Comment éviter d'écrire uniquement des tests bout-en-bout?
Comment faire cohabiter tout cela avec les tests unitaires?

Cette présentation montre à l'aide d'une démonstration technique de l'ATDD (avec Cucumber-JVM) comment faire pour d'abord écrire un test "petit" couvrant la logique d'affaires, puis écrire une deuxième implémentation du test pour couvrir le UI et l'infrastructure. Le tout en respectant la pyramide des tests!

Vous apprendrez comment faire cohabiter plusieurs implémentations du code de test ("glue / step definitions") pour un même scénario que votre intégration continue pourra filtrer et configurer dans un "pipeline".

Présentation technique (Java et Cucumber) et de niveau avancé. Le participant doit savoir au minimum utiliser un outil de test unitaire et connaître ce qu'est un test d'acceptation automatisé (ex.: Cucumber, SpecFlow, etc.).

Transcript

1. FÉLIX-ANTOINE BOURBONNAIS B.ING., M.SC, PSM Agile Tour Québec 2017 ATDD à double boucle automatiser un test d'acceptation
2. Diapositives, références et vidéos http://conferences.elapsetech.com/atdd-double-boucle Cette présentation s’adresse à un public avancé et très technique.
3. • Comprendre le cycle de l’ATDD • Comprendre comment piloter le développement à partir d’une User Story. • Comprendre le lien entre le TDD et l’ATDD • Savoir comment exécuter des scénarios à différents niveaux • Avoir un aperçu de comment enchaîner (pipeline) les tests Objectifs
5. Qu’est-ce qu’un test d’acceptation ou une Story Test ?
6. Est-ce que je produis la bonne chose? (Building the right thing) 8
7. Specification by Example Tests de Story Tests unitaires (type) Tests d’API Tests développeurs Tests de composantes Types de tests Les types de tests… Tiré du livre More Agile Testing Orienté AFFAIRES Orienté TECHNOLOGIE Guide le DÉVELOPPEMENT Guide le DÉVELOPPEMENT Critique le PRODUIT ATDD TDD
9. Tests d’acceptation/Story Tests != Tests bout-en-bout
10. La portée (scope) d’un test est la distance entre le point d’appel et de validation
11. Un type de test (ex.: Feature/Story) n’est pas directement relié à une portée (ex.: bout-en-bout).
12. Image par Gamma-Ray Productions sur Flickr Attention en automatisant ! % du portfolio de tests auto. (tous les types) Large (L) Moyen (M) Petit (S) ~10% ~20% ~70% Bout-en-bout Toutes composantes Une ou quelques classes Une composante intégrée Fragilité des tests
14. « Feature File »
15. Le Gherkin
16. Gherkin != BDD
17. Le BDD est une méthode axée sur la collaboration pour comprendre et spécifier les besoins d’affaires
19. • Cucumber et sa famille • SpecFlow Les outils en bref
20. • Feature File • Step Definitions / Glues • Support Classes (à venir) Anatomie de Cucumber
22. ATDD: Acceptance* Test Driven Development * Ne pas confondre avec les tests d’acceptation utilisateur. Acceptation ici = test des critères d’acceptation de la Story.
23. Le but de l’ATDD est de piloter le développement du système
24. Notre but est de nous assurer de répondre aux critères de la User Story et la considérer comme terminée.
25. ATDD 1 Écrire un scénario qui échoue 2 Scénario passe 3
26. • Java • Cucumber-JVM • Junit • Eclipse (IDE) • Maven Outils utilisés pour la démonstration
27. Démonstration <partie 1> Vidéo de la démonstration http://conferences.elapsetech.com/atdd-double-boucle
29. Constat: nous n’avons pas codé le UI et tous les tests passent !?!
30. La solution n’est pas de choisir la portée de chaque scénario.
31. ATDD à double boucle * Uniquement certains scénarios (voir Pyramide des tests). Pourrait être @MEDIUM ou autre portée… Logique (domaine) UI Infra / Données 2 c Scénario A @LARGE* 2 a 2 b Scénario A @SMALL 1 c 1 a 1 b
32. @scope=web Scenario: Transfering money adjusts the account balances Given an account 111 with 1000$ in it And an account 222 with 500$ in it When I create a transaction of 100$ from 111 to 222 Then the account 111 has 900$ in it And the account 222 has 600$ in it @scope=web Scenario: Transfering money creates an accepted transaction log Given an account 333 with 1000$ in it And an account 444 with 500$ in it When I transfer 100$ from 333 to 444 Then a transaction log is created for the amount of 100$ Scenario: Transfering money when the account doesn't have the funds Given an account 555 with 99$ in it And an account 666 with 500$ in it When I transfer 100$ from 555 to 666 Then a transaction log shows that the transfer was refused Exemple 1 2 1 2 1
33. Démonstration <partie 2> Vidéo de la démonstration http://conferences.elapsetech.com/atdd-double-boucle
35. Étape 1 • Nous avons écrit 1 Story Test pour nous assurer du comportement tel que spécifié dans la User Story. • Nous avons piloté l’écriture de la logique d’affaires pour faire passer le premier scénario. • Nous avons écrit des tests unitaires en TDD pour nous assurer de couvrir et bien construire le code de production. Résumé
36. Étape 2 • Nous avons branché le même scénario à une portée plus grande afin de piloter le développement de l’API (UI) Résumé
37. Étapes suivantes • Implémenter les autres scénarios avec la même boucle • Par contre, ces scénarios ne requièrent pas d’être pilotés à une portée plus grande que AppService+FakeDB. Résumé
38. Pourquoi ?
39. merci .
40. Site elapsetech.com Twitter @fbourbonnais Courriel fbourbonnais@elapsetech.com conferences.elapsetech.com Toutes nos présentations conferences.elapsetech.com /atdd-double-boucle Diapositives et références Pascal Roy @