Aprendendo TDD: montando minha suíte de testes

Ok, você começou seus estudos com Rails, gerou seu primeiro scaffold, ficou maravilhado com as facilidades do framework e questionou o fato de não ter conhecido antes essa ferramenta(ao menos comigo foi assim haha). Porém, você notou que quase toda a comunidade Ruby (principalmente os mais experientes) utilizam a pratica do TDD (desenvolvimento de software orientado a testes) em seus projetos. Mais ainda, praticamente TODAS as vagas para se trabalhar com Rails pedem TDD como pré-requisito principal.

Estou iniciando meu segundo ano trabalhando com Ruby/Rails e assumi que vou inserir cada vez mais a pratica de testes na minha rotina de trabalho, e com isso senti vontade de documentar esse processo de evolução para fixar o que eu aprendo, e tentar ajudar o pessoal que também está embarcando nessa vibe.

Objetivo de hoje

Minha proposta é escrever artigos simples, diretos ,envolvendo exemplos práticos e dividindo por temas. Então pensei em iniciar abordando uma forma de montar uma suite de testes bacana, aproveitando algumas ferramentas (gems) que notei serem bastante utilizadas pelo pessoal com mais experiência. Lembrando que eu não sou nenhum especialista na prática de testes, então vou ficar agradecido por cada feedback passado, seja ele positivo ou negativo ;)

Gems utilizadas

Nossa suíte de testes será composta pelas seguintes gems:

factory_girl_rails

A gem factory_girl_rails vai auxiliar a gente na definição dos objetos que usaremos nos nossos testes. Digamos que a gente precisa testar se um objeto foi persistido no banco, então com essa gem podemos definir quais são os atributos e quais são os valores que os atributos do objeto vão possuir.

faker

A gem faker faz uma ‘dobradinha’ legal com a factory girl , pois gera atributos de maneira dinâmica para um determinado objeto quando esse objeto for ser utilizado no teste. Isso é importante pois as vezes existem atributos que precisam ser unicos de cada objeto, como o atributo email de um usuário, por exemplo.

pry_rails

O pry-rails vai nos auxiliar no debug da nossa aplicação. É uma boa alternativa para o irb

rspec_rails

O Rails já vem com um framework de testes por padrão, o Test::Unit, mas o Rspec, ao meu ver, tem uma popularidade maior na comunidade e dispõe de uma DSL própria, o que para alguns é algo bom e para outros nem tanto. Não vou entrar no mérito de qual ferramenta é melhor, não tenho experiência pra isso, até por eu ter usado somente Rspec até hoje.

simplecov

A gem simplecov permite analisar quais linhas do nosso codigo Ruby foram testadas. Após a análise é gerado um HTM com o resultado da nossa cobertura de testes.

database_cleaner

Usaremos a gem database_cleaner para limpar nosso banco de dados sempre que terminarmos de executar nossos testes

shoulda-matchers

Para terstarmos funcinoalidades comuns do Rails (ex: testar um relationamento entre entidades), usaremos a shoulda-matchers.

Instalando e configurando

Vamos gerar nossa aplicação Rails com o comando “-T” no final para que o framework padrão de testes do Rails não seja instalado na nossa aplicação, já que usaremos o Rspec

rails new demo_tdd -T

Aplicação criada, vamos informar nossas gems no arquivo Gemfile e dar bundle logo após

Agora precisamos fazer algumas configurações.

Rspec

Execute o seguinte comando, no terminal.

rails generate rspec:install

Essa deverá ser a saída no seu terminal

create .rspec
create spec
create spec/spec_helper.rb
create spec/rails_helper.rb

O arquivo .rspec serve para definirmos, entre outras coisas, a formatação das saídas dos nossos testes (saída colorida, exibição dos testes em formato de documentação ou resumido. Vamos ver isso conforme os exemplos práticos forem acontecendo).

Também foi criado um diretório spec, nesse diretorio ficarão todos os nossos testes. E dentro desse diretório também notamos dois arquivos: spec_helper.rb e rails_helper.rb , onde vão conter as configurações do Rspec no nosso projeto.

Rode o comando rspec spec e a saída deverá ser a seguinte:

No examples found.

Finished in 0.00045 seconds (files took 0.21136 seconds to load)
0 examples, 0 failures

Factory Girl Rails / DatabaseCleaner

Dentro do diretório spec, vamos criar uma pasta chamada support e nela criaremos um arquivo chamado factory_girl.rb , onde definimos as configurações do factory girl para serem utilizadas com o Rspec, além das configurações da gem DatabaseCleaner, que será usada para limpar nosso banco de testes quando tivermos algum objeto persistido no banco . O arquivo conterá o seguinte:

RSpec.configure do |config|
  config.include FactoryGirl::Syntax::Methods
  config.before(:suite) do
     begin
       DatabaseCleaner.start
       FactoryGirl.lint
     ensure
       DatabaseCleaner.clean
     end
   end
end

Qualquer dúvida, pode dar uma olhada aqui .

SimpleCov

Adicione essas duas linhas no topo do seu arquivo spec_helper.rb . Rode mais uma vez o comando rspec spec e note o seguinte:

No examples found.

Finished in 0.00038 seconds (files took 0.39261 seconds to load)
0 examples, 0 failures

Coverage report generated for RSpec to /home/ricardo/open-source/demo_tdd/coverage. 0.0 / 0.0 LOC (100.0%) covered.

Embaixo aparece um mensagem informando que foi gerado um relatório a respeito dos seus testes. Para ver esse relatório, vá até o diretório coverage, que agora faz parte do seu projeto e abra o arquvo index.html. Qualquer dúvida é só dar uma olhada aqui, e ver como ficou o meu projeto.

Shoulda Matchers

Igualmente fácil de configurar, basta adicionar no seu arquivo rails_helper.rb,dentro do bloco RSpec.configure do |config|, o seguinte:

Shoulda::Matchers.configure do |config|
  config.integrate do |with|
    # Choose a test framework:
    with.test_framework :rspec

    # Choose one or more libraries:
    with.library :active_record
    with.library :active_model
    with.library :action_controller
    # Or, choose the following (which implies all of the above):
    with.library :rails
  end
end

Também é necessário declarar require ‘shoulda/matchers’ no rails_helper.rb , além de fazer uma pequena adição relacionada ao factory girl, conforme podemos ver aqui

Conclusão

Bom, para não ficar muito extenso, vou ficando por aqui. O endereço do projeto está nesse link e nele pretendo continuar inserindo os exemplos resultantes dos meus estudos sobre TDD.

Como falei anteriormente, vou tentar colocar aqui nos meus artigos tudo o que eu puder a respeito desse tema e, espero, além de fixar meu aprendizado, também ajudar outras pessoas que desejam aprender alguma coisa a mais sobre esse tema.

Qualquer dúvida, crítica ou dica, é só me mandar um ‘alô’ nos comentários abaixo, email ou facebook ;)

Até a próxima!