Ao rodarmos o RSpec, dessa
vez vemos o seguinte:
$ rspec --color --format documentation stack_spec.rb
Stack
#push
puts an element at the top of the stack
Finished in 0.00549 seconds
1 example, 0 failures
Figura 2.4: Teste no verde
Agora o teste passou! Chegamos ao passo green do ciclo red - green - refactor.
Agora que os testes estão no verde, podemos refatorar o teste e/ou o código para
melhorá-los. Refatorar é melhorar o código sem mudar seu comportamento externo,
não adicionando nenhum comportamento novo, apenas melhorando a qualidade
interna do nosso software.
Um ponto que podemos melhorar no nosso código é o modo como estamos
pegando o último elemento salvo na pilha. Ao invés de criar uma variável de ins-
tância para pegar o último elemento do array interno, podemos simplesmente fazer
elements[-1]. Passando -1 para índice do array, indicamos que estamos que-
rendo o último elemento adicionado.
Seguindo essa ideia, modifique o código para ficar assim:
class Stack
def initialize
@elements = []
end
11
2.1. Olá RSpec
Casa do Código
def push(element)
@elements << element
end
def top
@elements[-1]
end
end
Agora rode o RSpec novamente para checar se o teste está passando e o compor-
tamento previamente especificado continua funcionando:
$ rspec --color --format documentation stack_spec.rb
Stack
#push
puts an element at the top of the stack
Finished in 0.00549 seconds
1 example, 0 failures
Sucesso, o teste continua no verde! Isso quer dizer que conseguimos refatorar o
nosso código com sucesso. Melhoramos a qualidade interna sem quebrar nada que
já estava funcionando.
O passo seguinte seria escrever o próximo teste da classe Stack, talvez para o
método top, ou para um possível método pop (desempilha), seguindo o ciclo red
- green - refactor novamente. Esses eu deixarei como um desafio para você, apenas
replique o padrão que foi mostrado.
No capítulo 3 iremos entrar em detalhes no RSpec, entender essa sintaxe estra-
nha e as muitas nuances do framework. E a partir do capítulo 5 iremos construir
uma aplicação inteira fazendo TDD, usando RSpec do começo ao fim. Lá você terá
bastante tempo e exemplos para exercitar o ciclo red - green - refactor e aprender
como se constrói um software inteiro usando TDD.
Dando uma última olhada no código que escrevemos para fazer o teste com o
RSpec, dá para perceber que fizemos a descrição de um comportamento do nosso
código, através das seguintes linhas:
describe Stack do
describe "#push" do
it "puts an element at the top of the stack" do
12
Casa do Código
Capítulo 2. Primeiros passos com RSpec e Cucumber
Dissemos que estávamos Descrevendo (Describe) a classe Stack, em seguida
o seu método #push e por fim, falamos que ele coloca o elemento no topo da pilha.
Mas repare que misturamos código com o texto. Será que não há uma alternativa de
descrever nossa aplicação como um todo, apenas como um texto, um roteiro, e fazer
com que isso execute? Não seria mais natural?
Escrevo em português ou em inglês?
É muito comum se perguntar se a descrição do que está testando deve
ser feito em inglês ou em português. Pelo fato de o RSpec se basear no
inglês, fica mais natural manter tudo no mesmo idioma, além de que a
legibilidade fica maior quando se entende o idioma. Mas nada o impede
fazer as descrições em português.
Durante o livro, usaremos as descrições em inglês, mas daremos sem-
pre as explicações em português.
2.2
Olá Cucumber
O Cucumber é uma ferramenta de testes de aceitação, ou seja, serve para automatizar
testes do comportamento do software levando em conta o ponto de vista do usuário
final.
Ao escrever um teste com Cucumber, você irá especificar uma funcionalidade
do seu sistema, ao invés de especificar uma classe ou um método. De modo bem
resumido, entenda o Cucumber como uma espécie de documentação de requisitos
funcionais on steroids.
Eu digo isso, pois a proposta do Cucumber é ajudar a especificar o sistema com
documentos escritos em uma linguagem natural (inglês, português etc), porém
com
a possibilidade de executar essa documentação para verificar o comportamento es-
pecificado no sistema real. Ou seja, uma documentação executável.
O primeiro teste com Cucumber
Para ficar mais claro, vamos ver um exemplo de uma especificação escrita com
Cucumber.
Você foi contratado para desenvolver um pequeno jogo da forca, que irá funci-
onar no shell. Você conversa com o cliente, ele te explica o motivo de querer o jogo
e como ele pensa que ele irá funcionar.
13
2.2. Olá Cucumber
Casa do Código
Você entende o contexto inteiro e decide documentar a primeira funcionalidade
para então pedir ao cliente para conferir se o seu entendimento está correto. A pri-
meira funcionalidade que você imagina é a de Começar jogo, e você a documenta
do seguinte modo:
# language: pt
Funcionalidade: Começar jogo
Para poder passar o tempo
Como jogador
Quero poder começar um novo jogo
Cenário: Começo de novo jogo com sucesso