RETOUR
Les programmeurs d'aujourd'hui utilisent de plus en plus de pratiques agiles dans leur travail quotidien. Même les projets qui suivent un cycle de développement logiciel standard peuvent bénéficier de leur adaptation. Les tests automatiques et le TDD ont apporté plus de confiance dans notre travail, ont facilité la mise en œuvre des modifications des fonctionnalités existantes et nous ont souvent conduits à une meilleure conception du code. Mais aujourd'hui, cela ne suffit plus. Nous devons pousser les avantages des tests jusqu'à leurs limites, et c'est ce que permet le BDD. Il apporte un langage omniprésent au projet, permet une meilleure communication entre le client et les développeurs. Il apporte beaucoup aux chefs de projet et aux responsables, mais il facilite également la vie des développeurs. En suivant les principes de BDD, on obtient des exigences claires, les tests sont plus faciles à comprendre et peuvent servir de documentation. BDD déplace le centre d'intérêt des sujets de test et nous donne la certitude que nous testons ce que nous devrions tester - le comportement.
Si vous utilisez le TDD, il vous sera facile de commencer à utiliser le BDD - il s'agit essentiellement d'un ensemble de bonnes pratiques. BDD comporte un ensemble de règles simples qui indiquent comment rédiger les spécifications et ce qu'il faut tester. Les spécifications sont divisées en trois parties : Given (mise en place des conditions de test), When (invocation d'une action sur le sujet) et Then (assertions). Les tests doivent avoir des noms descriptifs et les cadres de test existants permettent d'utiliser des méthodes et des assertions qui sont similaires au langage naturel - tout cela combiné nous donne des tests qui sont lisibles par les utilisateurs techniques et non techniques. De bonnes conventions de dénomination s'avèrent utiles lors des tests de régression.
Le BDD s'accompagne également d'un ensemble de lignes directrices pour les sujets de test. Contrairement à la méthode TDD, elle met l'accent sur les tests de comportement plutôt que sur les tests d'implémentation, ce qui permet d'améliorer la conception et d'accroître la flexibilité lorsque des changements doivent être introduits. Les spécifications devraient être comme des exigences écrites et exécutables du client - les spécifications de haut niveau devraient agir comme des tests d'acceptation. L'objectif est d'écrire les tests de manière à ce qu'ils ne soient modifiés que lorsque les exigences changent. L'utilisation de BDD nous donne la certitude que nous testons ce qui doit vraiment être couvert et c'est une approche plus pragmatique que TDD.
Si vous voulez voir BDD en action, nous vous recommandons Ruby. C'est un langage puissant et agréable à utiliser et il dispose d'un excellent ensemble d'outils BDD.
Cucumber est le framework le plus populaire pour le BDD en Ruby. Il introduit un langage spécial, appelé Gherkin, dans lequel vous écrirez vos tests. Contrairement à RSpec, les fonctionnalités décrites dans Gherkin sont du texte brut, et non du codeet, en tant que tel, il peut - et doit - être compris par n'importe qui, en particulier par le client.
La fonctionnalité de Cucumber ressemble à ceci (exemple tiré du wiki de Cucumber) :
Fonctionnalité : Texte laconique mais descriptif de ce qui est souhaité
Description textuelle de la valeur commerciale de cette fonctionnalité
Les règles de gestion qui régissent le champ d'application de la fonctionnalité
Toute information supplémentaire qui facilitera la compréhension de la fonctionnalité.
Scénario : Une situation commerciale déterminable
Compte tenu d'une condition préalable
Et une autre condition préalable
Lorsqu'une action de l'acteur
Et une autre action
Et encore une autre action
Un résultat testable est obtenu
Et quelque chose d'autre que nous pouvons vérifier se produit également
Scénario : Une situation différente
...Les caractéristiques seront décrites plus loin en détail.
Première étape pour utiliser le concombre dans votre projet l'installe. Il suffit d'ajouter ces deux gemmes à votre Gemfile :
group :test do
gem 'cucumber-rails', :require => false
gem 'database_cleaner'
endRegroupez-les en lançant bundle installet générer des scripts et des répertoires Cucumber à l'aide de la commande suivante :
rails generate cucumber:install
Cela créera config/cucumber.yml, script/cucumber et caractéristiques/ répertoirequi contiendra .caractéristique ainsi que des définitions d'étapes et des fichiers de support. Pour exécuter vos fonctionnalités, utilisez une nouvelle commande rake :
ratisser le concombre
Examinons de plus près les fonctionnalités. Une fonctionnalité est quelque chose que votre application possède ou fait - par exemple, elle envoie périodiquement une lettre d'information ou permet à l'utilisateur de partager ses photos publiquement. Une fonctionnalité se compose de plusieurs scénarios, qui décrivent comment cette fonctionnalité fonctionne dans différents contextes.
Pour démontrer l'utilisation basique de Cucumber dans Rails, nous allons écrire une fonctionnalité à partir de zéro. Cet exemple de fonctionnalité sera le premier que nous écrirons dans l'application, qui sera présentée dans la seconde partie de cet article. Cette application permettra à l'utilisateur de créer des articles et des boutiques (les boutiques vendent des articles), puis de créer des listes d'achats.
Dans la version la plus simple, après avoir compilé la liste d'achats, l'application indique dans quels magasins les articles souhaités par l'utilisateur sont les moins chers.
Tout d'abord, créez un nouveau fichier nommé create_item.feature dans le caractéristiques/ répertoire. Au début d'un .caractéristique il y a un Fonctionnalité suivi d'une brève description. Par exemple :
Fonctionnalité : Création d'élémentsDans les lignes suivantes, vous pouvez écrire un objectif commercial qui mettra en œuvre cette fonctionnalité. Comme Cucumber ignore le texte écrit avant le premier scénario, il n'est pas nécessaire d'écrire quoi que ce soit, mais c'est certainement une bonne idée.
Pour créer facilement des listes d'achats avec des articles vendus dans les magasins voisins
En tant qu'utilisateur
Je veux ajouter des articles au systèmeDans l'extrait, vous pouvez voir un modèle assez populaire ci-dessus avec lequel vous pouvez décrire les objectifs de l'entreprise. Il se compose de trois parties : pourquoi la fonctionnalité est-elle nécessaire, qui la veut et en quoi elle consiste. Bien entendu, vous n'êtes pas obligé de suivre ce format, mais veillez à inclure les réponses à ces trois questions dans votre description.
Ensuite, nous rédigeons quelques scénarios. Chaque scénario commence par le mot-clé "Scénario" et contient plusieurs étapes.
Scénario : création d'un article unique
Il existe un article "Lait".
Lorsque je vais sur la page principale
Et je crée l'article "Pain
Je vois alors "Pain" dans la liste des articles. Ainsi, si quelqu'un a créé un article nommé Lait, la création de Pain est possible et entraîne l'apparition de Pain dans la liste des articles. Nous ne devrions pas tester la création d'un enregistrement dans la base de données, car ce fait n'a pas de valeur réelle pour le client.
Les étapes du scénario utilisent trois mots-clés principaux :
Il est important de noter que Cucumber ignore le mot-clé de l'étape qui commence et ne fait correspondre que la partie suivante. Vous pouvez donc commencer vos étapes par "Et" partout où cela vous semble naturel. La seule règle pour choisir le bon mot-clé est que le scénario doit être facilement compréhensible.
L'exécution de Cucumber produit maintenant la sortie suivante :
[...]
Fonctionnalité : Création d'articles
Afin de créer facilement des listes de courses avec des articles vendus dans les magasins voisins
En tant qu'utilisateur
Je souhaite ajouter des articles au système
Scénario : création d'un article unique # features/create_item.feature:6
Etant donné qu'il existe un article "Lait" # features/create_item.feature:7
Etape non définie : "il y a un élément "Lait"" (Cucumber::Undefined)
[...]C'est parce que Cucumber ne sait pas ce que nous voulons dire lorsque nous disons "il y a un article de lait". Pour donner un sens à vos étapes, vous devez les définir dans la section définitions_des_étapes répertoire.
Il est recommandé d'organiser les définitions d'étapes en les divisant par domaine. Par exemple, la plupart des étapes que nous avons créées appartiennent au domaine Item. Nous devrions donc créer un fichier nommé step_definitions/item_steps.rb et y placer le code suivant :
Étant donné "il y a un article "$name"" faire |name|
Fabriquer :article, nom : nom
fin
Lorsque "je crée un article "$name"" do |name|
dans "#new_item" faire
remplir "Nom", avec : nom
click_on "Créer"
end
fin
Then "Je vois "$name" dans la liste des éléments" do |name|
dans ".items" do
expect(page).to have_content name
end
finLes définitions des étapes sont généralement basées sur Capybara. Si vous ne connaissez pas Capybara, n'hésitez pas à consulter les liens à la fin de cet article.
Il y a une étape supplémentaire à définir et elle ne s'inscrit pas vraiment dans les étapes du point. Vous pourriez la placer dans main_page_steps.rb:
Quand "Je vais à la page principale" faire
visite le chemin d'accès principal
finIl s'agit d'une histoire très simple pour une fonctionnalité très simple. Son but était de démontrer les concepts de base de BDD tels qu'ils sont utilisés dans Cucumber. Écrire de bonnes histoires demande un peu plus d'efforts. En tant que développeur, vous devrez changer complètement d'état d'esprit - oublier l'implémentation et vous concentrer sur les objectifs de l'entreprise. Cucumber facilite cette transition grâce à son utilisation intelligente des histoires en texte clair.
Sources, inspirations et lectures intéressantes :
French 
English 
German 
Swedish 
Danish 
Norwegian 
Finnish 
Polish 
Arabic 
Italian 
Japanese 
Korean 
Spanish 
Dutch