Respostas:
O context
é um alias para describe
, portanto, eles são funcionalmente equivalentes. Você pode usá-los de forma intercambiável, a única diferença é como seu arquivo de especificação é lido. Não há diferença na saída do teste, por exemplo. O livro RSpec diz:
“Nós tendemos a usar
describe()
para coisas econtext()
para contexto”.
Pessoalmente, gosto de usar describe
, mas posso ver porque as pessoas preferem context
.
feature
e scenario
fazem parte do Capybara, e não do RSpec, e devem ser usados para testes de aceitação. feature
é equivalente a describe
/ context
e scenario
equivalente a it
/ example
.
Se você está escrevendo testes de aceitação com Capybara, use a feature
/ scenario
sintaxe, se não use describe
/ it
sintaxe.
Esta manhã, enquanto escrevia algumas especificações, tive a mesma pergunta. Normalmente, eu uso principalmente describe
e não penso particularmente sobre isso, mas esta manhã eu estava lidando com muitos casos e especificações diferentes para um módulo, então tinha que ser facilmente compreensível para o próximo desenvolvedor que lerá essas especificações. Então, perguntei ao Google sobre isso e achei o seguinte: descrever vs. contexto em rspec , cuja resposta acho bastante interessante:
De acordo com o código-fonte rspec, “contexto” é apenas um método de apelido de “descrever”, o que significa que não há diferença funcional entre esses dois métodos. No entanto, há uma diferença contextual que ajudará a tornar seus testes mais compreensíveis usando os dois.
O objetivo de “descrever” é agrupar um conjunto de testes em uma funcionalidade, enquanto o “contexto” é agrupar um conjunto de testes em uma funcionalidade no mesmo estado.
Portanto, com base neste princípio, você escreveria uma especificação como esta:
#
# 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
Não tenho certeza se essa é uma regra geralmente aceita, mas acho essa abordagem clara e muito fácil de entender.
Expandindo a excelente resposta de Pierre , de acordo com os documentos :
O recurso e o cenário DSL correspondem a descrevê-lo e a ele, respectivamente. Esses métodos são simplesmente apelidos que permitem que as especificações de recursos sejam lidas mais como testes de cliente e de aceitação.
Portanto, para aqueles familiarizados com os termos do Mocha descreva e ele (que são mais adequados para descrever o comportamento de um teste da perspectiva do usuário, portanto, o Mocha funciona principalmente como uma estrutura de teste de front end), você pode:
describe
e it
ou outro parit
dentro de um context
bloco que requer várias asserções / testes a serem feitos em um estado específico do aplicativoIndo com a segunda opção, você ainda pode seguir a intenção de "... agrupar [ping] um conjunto de testes contra uma funcionalidade sob o mesmo estado".
Portanto, seus testes podem ter a seguinte aparência:
#
# 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
Dessa forma, você pula a feature
palavra - chave totalmente, que pode ser útil para recursos de front end específicos ou se estiver fazendo FDD (desenvolvimento orientado por recurso), o que pode ser desconfortável para alguns. Peça informações à sua equipe de desenvolvedores aqui.
Advertência: nem sempre siga os padrões da indústria, imagine se modelássemos todos os nossos testes de acordo com a filosofia da Volkswagen?