Utilisation du BDD avec Robot Framework dans Squash – Rédaction des cas de test
Rédaction des cas de test
| Annita Administratrice Squash TM |
Pravash Product owner |
Fabrice Testeur fonctionnel |
Antonine Automaticienne |
|---|---|---|---|
| Configurer Squash TM | |||
| Rédiger les exigences | |||
| Rédiger les cas de test | |||
| Transmettre les cas de test | |||
| Récupérer les cas de test | |||
| Automatiser les cas de test | |||
| Fournir les cas de test automatisés | |||
| Indiquer que l’automatisation est effectuée | |||
| Exécuter les tests automatisés |
Pendant les sessions de raffinement (grooming), Pravash explique à toute l'équipe (Scrum master, développeurs et Fabrice) les fonctionnalités qu'il souhaite intégrer au produit. Pour chaque fonctionnalité, les développeurs et Fabrice demandent des détails à Pravash (cas nominaux, cas d'erreur, cas limites…). Ensuite, l'équipe définit ensemble un ou plusieurs cas d'utilisation et les rédige en utilisant la syntaxe Gherkin. Cela garantit que tout le monde partage la même compréhension de ce qui doit être mis en œuvre et que cette compréhension est capitalisée.
Un aperçu de la syntaxe Gherkin
- Given (Etant donné) : Décrit un prérequis, c'est-à-dire une condition préalable pour que le scénario soit applicable. Toutes les conditions préalables définissent l'état initial (ou du moins la partie pertinente de l'état initial) du système avant le début du cas d'utilisation.
- When (Quand) : Décrit une action effectuée pendant le test. Les actions sont exécutées dans l'ordre spécifié.
- Then (Alors) : Décrit un résultat, c'est-à-dire une postcondition, qui doit être remplie à la fin du test. Tous les résultats définissent l'état final attendu (ou du moins la partie pertinente de l'état final) du système après la fin du cas d'utilisation.
Certaines conjonctions peuvent être utilisées pour éviter de répéter les mots précédents (elles ont la même signification que la répétition du mot) :
- And
- But
Exemples :
Scenario: Un utilisateur retire de l'argent de son compte bancaire
Given Eric possède une carte de débit basique valide
And le solde de son compte est de 100 $
When il insère sa carte
And il retire 45 $
Then le distributeur doit lui donner 45 $
And le distributeur lui rend sa carte
And le solde de son compte est de 55 $
Scenario: Un utilisateur tente de retirer plus d'argent qu'il n'en a sur son compte
Given Vsevolod possède une carte de débit basique valide
And le solde de son compte est de 20 $
When il insère sa carte
And il retire 40 $
Then le distributeur affiche alors une erreur
And le distributeur lui rend sa carte
But le solde de son compte reste de 20 $
Les Doc Strings peuvent être utilisées pour définir un grand morceau de texte. Elles sont délimitées par trois guillemets doubles.
Exemple :
Then le distributeur affiche le message d'erreur suivant
"""
Retrait refusé
================
Votre carte de débit ne vous permet pas de retirer plus d'argent que le solde de votre compte courant.
Veuillez contacter votre conseiller bancaire.
"""
Les Data Tables peuvent être utilisées pour définir une liste de valeurs dans une action. Exemple :
Given les cartes de débit existent :
| nom | découvert autorisé | durée maximale du découvert (jours) |
| basique | 0 $ | 0 |
| gold | 500 $ | 15 |
| platinum | 3000 $ | 42 |
Il est possible de regrouper des scénarios ayant les mêmes actions, mais des valeurs différentes en utilisant un Scenario Outline et des caractères de remplacement entre < et >.
Exemple :
Scenario Outline: Un utilisateur retire de l'argent à un distributeur
Given <Nom> possède une carte de débit basique valide
And le solde de son compte est <SoldeInitial>
When il insère sa carte
And il retire <MontantDuRetrait>
Then le distributeur devrait lui donner <MontantDuRetrait>
And le distributeur lui rend sa carte
And le solde de son compte est <NouveauSolde>
Exemples :
| Nom | SoldeInitial | MontantDuRetrait | NouveauSolde |
| Eric | 100 | 45 | 55 |
| Gaurav | 100 | 40 | 60 |
| Ed | 1000 | 200 | 800 |
Un exemple de scénario noté par Fabrice :
Create an account, then check login and personal data
Given I am on the AccountCreation page
When I fill AccountCreation fields with gender <gender> firstName <first> lastName <last> password <password> email <mail> birthDate <birth> acceptPartnerOffers <offers> acceptPrivacyPolicy <privacy> acceptNewsletter <news> acceptGdpr <gpdr> and submit
And I go to the Home page
And I sign out
Then I can successfully sign in with email <mail> password <password>
And The displayed name is <display>
And My personal information is gender <gender> firstName <first> lastName <last> email <mail> birthDate <birth> acceptPartnerOffers <offers> acceptPrivacyPolicy "no" acceptNewsletter <news> acceptGdpr "no"
Examples:
| gender | first | last | display | password | mail | birth | offers | privacy | news | gpdr |
| "M" | "John" | "Doe" | "John Doe" | "mypassword" | "jdoe@example.com" | "1990-01-02" | "no" | "yes" | "yes" | "yes" |
| "F" | "Jane" | "Doe" | "Jane Doe" | "123&µ" | "jane.doe@oo.com" | "1992-01-02" | "yes" | "yes" | "yes" | "yes" |
| "U" | "Camille" | "Bertillon" | "Camille Bertillon" | "£→µ$¤11" | "cb@gmail.com" | "1968-02-10" | "yes" | "yes" | "no" | "yes" |
| "U" | "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" | "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" | "abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz" | "012345678901234567890123456789012345678901234567890123456789" | "012345678901234567890123456789012345678901234567890123456789@oo.com" | "2022-02-10" | "yes" | "yes" | "yes" | "yes" |
Fabrice enregistre ces scénarios Gherkin comme des cas de test BDD dans Squash TM et les lie aux exigences telles que définies dans la documentation Squash TM :
Transmission des cas de test
| Annita Administratrice Squash TM |
Pravash Product owner |
Fabrice Testeur fonctionnel |
Antonine Automaticienne |
|---|---|---|---|
| Configurer Squash TM | |||
| Rédiger les exigences | |||
| Rédiger les cas de test | |||
| Transmettre les cas de test | |||
| Récupérer les cas de test | |||
| Automatiser les cas de test | |||
| Fournir les cas de test automatisés | |||
| Indiquer que l’automatisation est effectuée | |||
| Exécuter les tests automatisés |
Une fois qu'un cas de test a été revu et approuvé (voir documentation Squash TM), Fabrice le signale comme éligible à l'automatisation (voir Squash TM documentation) et, éventuellement, définit une priorité d'automatisation. Il peut maintenant transmettre le scénario de test en cliquant sur la flèche :
La transmission du cas de test a deux effets :
- le fichier
robotest généré et est poussé vers le dépôt Git distant quelques minutes plus tard ; - le cas de test apparaît dans l’Espace Automatisation.