Começando com TDD + Rspec
Fala pessoal, tudo certo? Vim trazer um assunto muito interessante e que eu tinha muita dificuldade pra dar aquele start, o tal do TDD. A ideia é passar uma noção do que é e como vocês podem começar a praticar, utilizando como exemplo Ruby + Rspec. Para quem utiliza o docker, vou disponibilizar também os arquivos dockerfile e docker-compose, que foi o utilizei aqui.
Mas afinal, que é o TDD?
A ideia do TDD ou Test Driven Development é simples, consiste em começarmos o desenvolvimento de uma rotina ou funcionalidade a partir dos testes. Para fazermos isso, utilizamos o TDD, além de outras estratégias. Isso faz com que tenhamos confiança ao realizar mudanças ou adicionar novas rotinas à códigos que estão em produção, pois sabemos que existe um teste que garante seu funcionamento e que isso não causará um efeito colateral. Mas é claro que não existe milagre, os bugs, mesmo com TDD, continuarão existindo, mas em uma proporção bem menor!
Porém, muitos de nós (incluindo eu), programadores, temos dificuldades em começar a utilizar, já que é um conceito diferente do que estamos acostumados a praticar diariamente quando estamos na faculdade ou recém formados.
A ideia do TDD ou Test Driven Development é simples, consiste em começarmos o desenvolvimento de uma rotina ou funcionalidade a partir dos testes!
E é aqui que eu e muitas pessoas começamos a bater a cabeça. “Como assim testar algo que ainda nem existe?”. Pois é, exatamente isso; criamos um teste para uma funcionalidade que planejamos, colocando quais os resultados esperados. Então, a partir dai escrevemos a funcionalidade com o menor código possível para que o teste passe e depois refatoramos o código da funcionalidade para que ela tenha uma qualidade aceitável. Essa sequência é conhecida como “Red, Green, Refactor”.
Entendendo o TDD
Agora que já temos uma noção do que é o TDD, vamos tentar entender um pouco melhor antes da parte prática. As etapas que envolvem um ciclo de desenvolvimento com testes são as seguintes:
1 — Criação do teste
No TDD, antes de qualquer funcionalidade ser desenvolvida, deve-se criar um teste correspondente. O desenvolvedor então deve ter conhecimento claro de quais os requisitos da funcionalidade a ser criada, ANTES de ela realmente ser criada!
2 — Executar os testes
Aqui devemos executar os testes existentes. A ideia é que os testes já existentes passem e o novo teste criado NÃO PASSE! O novo teste, preferencialmente não deve quebrar os testes já existentes e deve passar somente nos casos em que a funcionalidade a ser desenvolvida funcione adequadamente de acordo com seu requisito.
3 — Escrever o código da funcionalidade
Agora que já temos o teste, podemos começar a escrever a nossa funcionalidade. Devemos tentar escrever o menor código que faz nosso teste passar (no exemplo ficará mais claro), sem se preocupar ainda com a qualidade do código e da funcionalidade em si.
4 — Rodar os testes
Nesta etapa, executamos os testes para ver se o código desenvolvido é capaz de fazer passar. Podemos executar os testes várias vezes durante o desenvolvimento da funcionalidade para avaliarmos qual caminho devemos tomar de acordo com os erros mostrados, mas não devemos seguir para a próxima etapa enquanto o teste NÃO estiver passando!
5 — Refatorar e melhorar o código da funcionalidade
Agora que a funcionalidade foi testada e seu resultado está de acordo com o seu requisito, podemos refatorar o seu código se necessário. Essa regra pode ser utilizada sempre que acharmos necessário, como por exemplo, se o código de uma funcionalidade ficar muito grande ou duplicado. O que não podemos esquecer aqui é de SEMPRE rodar os testes quando uma modificação for feita! Vamos para um exemplo prático então…
Testando na Prática
Utilizarei para o exemplo, Ruby e a gem RSPEC, além de utilizar o docker como ambiente, porém somente o RUBY e o RSPEC são obrigatórios, o ambiente você pode utilizar o que achar melhor!
Neste exemplo, a ideia é criar uma funcionalidade de soma de dois números. Para isso, criei um projeto do zero e adicionei o RSPEC ao gemfile (os arquivos dockerfile e docker-compose.yml são apenas para o ambiente que utilizei, o docker).
Agora, no terminal podemos rodar o comando “bundle install” para instalar a gem. Com ela instalada, basta rodar rspec --init para que o rspec seja configurado no projeto.
Vamos então criar nosso teste de soma. Para isso, vamos criar um arquivo conta_spec.rb que é o arquivo referente a nossa classe de Contas. Todos os arquivos do rspec devem terminar em “_spec.rb”. Coloquei alguns comentários referente a sintaxe do rspec, mas não entrarei em detalhes neste post.
Para rodar nossos testes, no terminal dentro do projeto devemos rodar o comando:
Ao fazermos isso, devemos notar no terminal o seguinte erro:
Isso quer dizer que a classe “conta”que estamos instanciando não foi encontrada. Vamos então, criar apenas a nossa classe (na pasta classes) e importá-la ao teste, conforme a seguir:
Agora, rodando novamente o teste, vamos ver que o erro mudou para:
“NoMethodError:
undefined method `soma’ for #<Conta:0x000055607ac61d50>”
Ou seja, não foi encontrado o método “soma”. Portanto, devemos criá-lo. Vamos voltar à nossa classe Conta e criar o método:
Agora, vamos rodar novamente os testes. Veremos que o erro mudou, agora teremos como erro o número de parâmetros do método:
“ArgumentError:
wrong number of arguments (given 2, expected 0)”
Ou seja, precisamos refatorar novamente a nossa classe de Conta. Você já deve ter reparado que vamos sempre testando, adequando a função ou método, testando novamente e assim por diante. E essa é a ideia mesmo, vamos corrigindo de acordo com os erros que são indicados, etapa por etapa.
Ao final, teremos os testes em verde, o que significa que ele passou e podemos então refatorar nosso código da funcionalidade. Para não estender muito, a ideia é deixar o método e teste da seguinte maneira no final:
Se você reparar, ao final mudamos a descrição do nosso teste para “retorna a soma de dois números”, o que significa que refatoramos nosso método para, ao invés de retornar a soma de 5+5, retornar a soma de dois números quaisquer.
Refatorar os testes também faz parte do TDD
Considerações Finais
Ao utilizarmos os testes automatizados, podemos reduzir o tempo de entrega e teste de um item de um sistema, além de termos mais confiança nas mudanças que são necessárias nas funcionalidades. Porém, esta não é uma técnica salvadora que eliminará os bugs dos códigos desenvolvidos, mas pode reduzir bastante os mesmos.
Espero que vocês tenham gostado e até mais :)
Bônus
Para quem utiliza o docker, vou deixar abaixo os arquivos que utilizei para subir o ambiente:
