RSpec: décrire, contexte, fonctionnalité, scénario?

describe , context , feature , scenario : Quelle (s) différence (s) entre les quatre et quand est-ce que je les utilise?

Le contexte est un alias pour describe et donc fonctionnellement équivalent. Vous pouvez les utiliser indifféremment, la seule différence réside dans la lecture de votre fichier de spécifications (il n’y a pas de différence dans la sortie de test par exemple). Le livre de Rspec dit:

“Nous avons tendance à utiliser describe() pour les choses et context() pour le contexte”.

Personnellement, j’aime juste utiliser describe() , mais je peux voir pourquoi les gens préfèrent le context() .

La fonction et le scénario font partie de Capybara, et non pas rspec, et sont destinés à être utilisés pour les tests d’acceptation.

La fonctionnalité est équivalente à description / contexte et à un scénario équivalent à celui-ci / exemple.

Si vous écrivez des tests d’acceptation avec Capybara, utilisez la syntaxe de fonctionnalité / scénario, sinon utilisez la syntaxe describe / it.

Ce matin, en écrivant quelques spécifications, je me posais la même question. Habituellement, j’utilise principalement describe et ne pense pas particulièrement à cela, mais ce matin, je traitais avec beaucoup de cas et de spécifications différentes pour un module, donc il devait être facilement compréhensible pour le développeur suivant qui lira ces spécifications. J’ai donc posé la question à Google, et j’ai trouvé ceci: décrivez vs. contexte dans rspec , dont je trouve la réponse très intéressante:

Selon le code source de rspec, «context» est simplement une méthode alias de «describe», ce qui signifie qu’il n’ya pas de différence fonctionnelle entre ces deux méthodes. Cependant, il existe une différence contextuelle qui vous aidera à rendre vos tests plus compréhensibles en les utilisant tous les deux.

Le but de la description est d’envelopper un ensemble de tests par rapport à une fonctionnalité, alors que le contexte consiste à placer un ensemble de tests sur une fonctionnalité du même état.

Donc, en vous appuyant sur ce principe, vous écririez une spécification comme celle-ci:

 # # The feature/behaviour I'm currently testing # describe "item ordering" do # 1st state of the feature/behaviour I'm testing context "without a order param" do ... end # 2nd state of the feature/behaviour I'm testing context "with a given order column" do .. end # Last state of the feature/behaviour I'm testing context "with a given order column + reverse" do .. end end 

Je ne suis pas sûr que ce soit une règle généralement acceptée, mais je trouve cette approche claire et facile à comprendre.