Réponses:
Le context
est un alias pour describe
, donc ils sont fonctionnellement équivalents. Vous pouvez les utiliser de manière interchangeable, la seule différence est la lecture de votre fichier de spécifications. Il n'y a pas de différence de sortie de test par exemple. Le livre RSpec dit:
"Nous avons tendance à utiliser
describe()
pour les choses etcontext()
pour le contexte".
Personnellement, j'aime utiliser describe
, mais je peux voir pourquoi les gens préfèrent context
.
feature
et scenario
font partie de Capybara, et non de RSpec, et sont destinés à être utilisés pour les tests d'acceptation. feature
est équivalent à describe
/ context
, et scenario
équivalent à it
/ example
.
Si vous écrivez des tests d'acceptation avec Capybara, utilisez la syntaxe feature
/ scenario
, sinon utilisez la syntaxe describe
/ it
.
Ce matin, en écrivant quelques spécifications, j'avais la même question. Habituellement, j'utilise principalement describe
et je n'y pense pas particulièrement, mais ce matin, je traitais de nombreux cas et de différentes spécifications pour un module, donc cela devait être facilement compréhensible pour le prochain développeur qui lira ces spécifications. J'ai donc interrogé Google à ce sujet, et j'ai trouvé ceci: décrire vs contexte dans rspec , dont je trouve la réponse assez intéressante:
Selon le code source de rspec, «context» est juste une méthode d'alias de «décrire», ce qui signifie qu'il n'y a pas de différence fonctionnelle entre ces deux méthodes. Cependant, il existe une différence contextuelle qui aidera à rendre vos tests plus compréhensibles en utilisant les deux.
Le but de «décrire» est d'encapsuler un ensemble de tests par rapport à une fonctionnalité tandis que «contexte» est d'encapsuler un ensemble de tests par rapport à une fonctionnalité sous le même état.
Donc, en vous basant 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 sais pas si c'est une règle généralement acceptée, mais je trouve cette approche claire et assez facile à comprendre.
Poursuivant l' excellente réponse de Pierre , selon la documentation :
La fonctionnalité et le scénario DSL correspondent respectivement à la description et au scénario. Ces méthodes sont simplement des alias qui permettent aux spécifications de fonctionnalités de se lire davantage en tant que tests client et d'acceptation.
Donc, pour ceux qui sont familiers avec les termes Mocha décrivent et il (qui sont mieux adaptés pour décrire le comportement d'un test du point de vue d'un utilisateur, d'où Mocha fonctionnant principalement comme un cadre de test frontal), vous pouvez:
describe
et / it
ou un autre couplageit
intérieur d'un context
bloc qui nécessite plusieurs assertions / tests dans un état d'application spécifiqueAvec la deuxième option, vous pouvez toujours suivre l'intention de "... envelopper [ping] un ensemble de tests contre une fonctionnalité sous le même état".
Ainsi, vos tests pourraient ressembler à ceci:
#
# The feature/behaviour I'm currently testing
#
describe "item ordering" do
# 1st state of the feature/behaviour I'm testing
context "without an order param" do
# 1st and only test we want to run in this state
it "asks the user for missing order param" do
...
end
end
# 2nd state of the feature/behaviour I'm testing
context "with an invalid order param" do
# 1st test we want to run in this state
it "validates and rejects order param" do
...
end
# 2nd test we want to run in this state
it "returns an error to user" do
...
end
end
# 3rd state of the feature/behaviour I'm testing with multiple tests
context "with a valid order param" do
it "validates and accepts order param" do
...
end
it "displays correct price for order" do
...
end
unless being_audited
it "secretly charges higher price to user" do
...
end
end
end
end
De cette façon, vous ignorez feature
complètement le mot - clé, que vous voudrez peut-être utiliser pour des fonctionnalités frontales spécifiques ou si vous faites du FDD (développement piloté par les fonctionnalités), ce qui peut sembler inconfortable pour certains. Demandez à votre équipe de développeurs de vous aider ici.
Attention: ne suivez pas toujours les normes de l'industrie, imaginez si nous modélisons tous nos tests sur la philosophie de Volkswagen?