Rachid Calazans de Viveiros

August 30, 2021

RSpec - Método `.it`, como utilizá-lo de forma correta

Hoje vamos falar do método de classe .it que o RSpec disponibiliza.

Os links dos posts da série sobre Métodos do RSpec estão no final desse post.

A intenção do método .it  é descrever as expectativas que a funcionalidade/método precisa realizar como resultado final de algum fluxo de sucesso ou falha.

O método .it pode receber uma String como parâmetro:

#1. Uma descrição do que é esperado acontecer
it('returns a created user')

Assim como nos métodos .describe e .context, o .it também deve expressar uma conversa. A melhor descrição é a que deixe claro qual é o resulto final esperado daquele teste. Fazendo o comparativo com a palavra chave no BDD (Behavior Driven Development) é o então/then. Ou seja, Então esse teste espera retornar um usuário criado como resultado (tradução de uma possível conversa do exemplo acima).

Vamos analisar alguns exemplos de como aplicar o .it dentro do cenário que utilizamos no post anterior sobre o método .context:

RSpec.describe User, 'model' do
  describe '.create' do
    context 'When given valid params' do
      it 'creates a new valid user' do
        # código com as expectativas
        # expect(1).to be == 1
      end
    end
  end

  describe '.update' do
    context 'Success Scenario', 'when given valid params' do
      it 'updates the given user' do
      end
    end

    context 'Fail Scenarios' do
      context 'When given invalid params' do
        it 'raises an exception' do
        end
      end

      context 'When the given user is nil' do
        it 'raises an exception' do
        end
      end
    end
  end

  describe '.all' do
    context 'When does NOT have any user' do
      it 'returns an empty list' do
      end
    end

    context 'When does have users' do
      it 'returns a list of users' do
      end
    end
  end
end

Com o exemplo acima podemos observar alguns pontos:

  1. Dentro do método it é onde fazemos as implementações dos testes com as expectativas finais que queremos validar.
  2.  As descrições do it é de certa forma genérica, ou seja, evitamos colocar na descrição alguma regra de negócio ou tipos das classes que irão ser retornadas ou classes de erros com suas mensagens. Nesse caso não deixamos as descrições muito rígidas para alterações das expectativas, por exemplo, se a mensagem do erro mudar ou se a própria classe de erro for alterada, não precisamos mexer na história que o teste está informando.

O importante é que suas histórias estejam claras e consistentes com todos os fluxos que seus testes precisam cobrir.

Obrigado.


Posts da série sobre Métodos RSpec: