automatizados. Comece primeiro especificando o comportamento de uma funcio-
nalidade. Depois disso, especifique as classes e métodos que serão necessárias para
implementar essa funcionalidade.
À prática de começar o desenvolvimento de uma funcionalidade com testes de
aceitação e depois fazer os testes de unidade, se dá o nome de acceptance test-driven development (ATDD). Essa é uma das práticas nas quais o BDD se baseia. Uma das
outras práticas é o famoso domain-driven design [4].
A partir do capítulo 5 nós iremos desenvolver uma aplicação seguindo o fluxo de
BDD. Começaremos por testes de aceitação com Cucumber e em seguida faremos
testes de unidade com RSpec. Mas antes de começarmos a desenvolver o projeto,
você precisa aprender mais sobre o RSpec e o Cucumber, e é isso que faremos nos
capítulos a seguir.
22
Capítulo 3
Introdução ao básico do RSpec
Neste capítulo você irá aprender como usar o RSpec para fazer testes de unidade.
Iremos ver como o RSpec pode nos ajudar a escrever testes que sejam legíveis e que
possam servir não só como testes de regressão mas também como mais uma fonte
de documentação do nosso código.
3.1
Aprendendo a estrutura básica de um teste com
RSpec
Para começarmos a entender a estrutura de um teste com RSpec, vamos dar uma
olhada no que fizemos no capítulo anterior:
describe Stack do
describe "#push" do
it "puts an element at the top of the stack" do
stack = Stack.new
3.1. Aprendendo a estrutura básica de um teste com RSpec
Casa do Código
stack.push(1)
stack.push(2)
expect(stack.top).to eq(2)
end
end
end
A primeira coisa que estamos fazendo nesse teste é chamar o método describe:
describe Stack do
# (...)
end
O método describe serve para agrupar os nossos testes. No que acaba-
mos de fazer, usamos um describe para agrupar as specs da classe Stack
e um
describe aninhado para agrupar especificamente as specs do método
Stack#push. O modo como estamos usando o describe aninhado para agru-
par os testes relacionados somente ao comportamento do método Stack#push é
apenas uma convenção, poderíamos ter feito sem usar um describe aninhado:
describe Stack do
it "puts an element at the top of the stack" do
stack = Stack.new
stack.push(1)
stack.push(2)
expect(stack.top).to eq(2)
end
end
Mais para frente vamos falar mais dessa convenção. Vamos agora entender para
que serve o método it.
O método it serve para criarmos um teste de fato. Dentro do bloco que pas-
samos para o it é onde é escrito um exemplo de como o nosso código deve se
comportar em um determinado contexto. No exemplo que fizemos acima temos o
seguinte teste:
it "puts an element at the top of the stack" do
stack = Stack.new
24
Casa do Código
Capítulo 3. Introdução ao básico do RSpec
stack.push(1)
stack.push(2)
expect(stack.top).to eq(2)
end
Perceba como o código escrito é apenas uma chamada do método it. Ele está
sendo chamado com dois argumentos. O primeiro é a string que contém uma des-
crição do teste. O segundo argumento é um bloco com o código do teste em si,
delimitado pelo do e end.
A terceira, e última parte básica de um teste com RSpec, é a asserção, que é onde
verificamos se o nosso código se comportou do modo esperado. No RSpec as asser-
ções são feitas com expectations. No teste acima a expectation que estamos fazendo
é a parte onde checamos se o topo da pilha contém o elemento 2:
expect(stack.top).to eq(2)
A estrutura de uma expectation segue a seguinte forma:
expect(actual).to matcher(expected)
ou:
# usando to_not
expect(actual).to_not matcher(expected)
# usando not_to
expect(actual).not_to matcher(expected)
Onde actual é o objeto do qual você está testando algum comportamento,
expect é um método do RSpec para iniciar uma expectation e matcher é um
objeto que segue o protocolo do RSpec::Matchers e serve para testar de fato o
comportamento esperado do seu objeto.
No caso do nosso teste anterior, o matcher usado foi o eq, que testa se o seu
objeto é igual ao valor esperado usando o operador ==. Ou seja, o que fizemos no
nosso teste foi verificar se o valor retornado pelo método stack.top era igual ao
valor esperado, 2.
25
3.2. Porquê existem tantos matchers no RSpec
Casa do Código
Diferentes sintaxes de expectation: expect X should
Se você já viu ou escreveu algum teste com RSpec antes de ler este
livro, é provável que você tenha visto a sintaxe antiga do RSpec para criar
expectations, que era usando o método should.
Antigamente, o padrão de expectations do RSpec era do seguinte
modo:
stack.top.should eq(2)
ao invés de:
expect(stack.top).to eq(2)
Na versão 2.11 do RSpec a nova sintaxe expect foi introduzida, e
desde então é a sintaxe recomendada pelo equipe core do RSpec.
Se você tiver interesse, você pode ver o porquê dessa mu-
dança
em
um
post
(http://myronmars.to/n/dev-blog/2012/06/
rspecs-new-expectation-syntax) no blog do Myron Marston, atual
mantenedor do RSpec.
Visto tudo isso, agora você já conhece a estrutura básica de um teste com RSpec.