[Ruby] Testando Features, Views e Requests

Henrique Fernandez
Jul 16, 2018 · 7 min read
Image for post
Image for post

Através desse post vamos entender como testar Features, Views e Requests de maneira automatizada.

Apesar do conceito se tornar simples para desenvolvedores mais experientes, a diferença entre estes três tipos de testes muitas vezes não é muito clara, principalmente para quem está começando. Frequentemente há dúvidas como:

Exemplos no stack overflow:

Chega de dúvidas!

Teremos as repostas para todos estes questionamentos.

A linguagem que usaremos para os exemplos será Ruby, por ser mais simples e fácil de ler.

Utilizarei também o framework RSpec para os testes, mas fique tranquilo, com certeza haverão ferramentas semelhantes para a sua linguagem! 😄

Testando Features

Image for post
Image for post

O que são features?

“feature” é uma palavra em inglês que significa “característica”

No mundo do desenvolvimento essa palavra também nos remete a “funcionalidade” ou algo que tem uma função.

Logo, como podemos saber quais são as features no nosso sistema?

Simples! é basicamente o que seu sistema faz de maneira macro. Mais resumido ainda: features são as funcionalidades através da visão do usuário.

Suponhamos que iremos utilizar o caixa eletrônico de um banco qualquer:

Quais poderiam ser as features do sistema do caixa? A resposta é:

Se perguntarmos para um usuário leigo o que um determinado sistema faz, descobriremos bem rápido as suas features!

— Tá, mas e os testes?

Observe o exemplo abaixo:

Olha só o que acontece quando jogamos esse trecho de código Ruby em algum software de tradução (de inglês para português):

Graças a alta legibilidade da linguagem, o código acabou se tornando auto-explicativo:

Já que as features são as funcionalidades do seu sistema de maneira macro, nada melhor do que testa-las dessa maneira!

O teste de feature é basicamente a simulação de um usuário utilizando o sistema, para cada funcionalidade. Ou seja, simulamos cliques de botões e links, além de preenchimentos e submissões de formulários.

Por aqui, todas as camadas do sistema são envolvidas, banco de dados, models, controllers, views e o que mais tivermos. Por isso esse tipo de teste é bem importante, é um teste completo da funcionalidade(feature).

Para conseguirmos testar features de maneira mais efetiva os frameworks de testes nos fornecem funções como:

Além disso, eles geralmente utilizam ferramentas que simulam ou rodam um browser por trás. Alguns, como o Rspec, dão até a possibilidade de escolher o tipo do browser (Chrome, IE, Mozila).

Testando Views

Image for post
Image for post

No padrão MVC, view é a camada onde temos a apresentação dos dados para o usuário. De maneira isolada, uma view não deve carregar nenhuma lógica de negócio. Se isso estiver acontecendo, há algo bem errado com o seu sistema.

Uma view também não sabe como recuperar dados do banco, muito menos trata-los. Ela apenas os renderiza de maneira elegante.

Para testa-las, não precisamos realizar nenhum contato com controllers ou models. Afinal, queremos apenas garantir que ela por si só funciona de acordo com o esperado. Logo, teremos que simular os dados que ela receberia caso estivesse em real utilização.

Veja um exemplo:

Usando a mesma técnica do último tópico, traduzimos o teste acima:

No teste acima há a simulação dos dados e o próprio preenchimento das variáveis contidas na view para realização do template (como as variáveis meu_titulo e widgets), logo, fazemos as asserções para garantir que a view foi renderizada como esperado.

stub_model é uma função utilizada para criarmos uma simulação da instância de um objeto, passando uma classe, no caso, simulamos a criação de um objeto Widget, que tenha o atributo name.

Para testarmos views, as ferramentas de testes nos fornecem funções como:

Testando Requests

Image for post
Image for post

Requests! O ponto principal de uma aplicação web. Sem elas nada aconteceria.

Quando falamos em requests, estamos mencionando todos os dados que compõe uma requisição web, e os tipos de respostas esperados para essa requisição:

Ao testarmos requests na nossa aplicação, buscamos validar nosso comportamento e o tipo de resposta que retornaremos a partir de uma requisição recebida.

Primeiro, configuramos como queremos enviar a requisição para o nosso sistema, após isso, a enviamos para um de nossos endpoints.

Tradução:

Nesse caso, temos um teste que lista todas as contas que o usuário deve pagar.

O que fizemos:

  1. Criamos um usuário teste
  2. Criamos uma conta a pagar para o usuário
  3. Enviamos uma requisição get para o endpoint /bills
  4. Verificamos se a resposta foi igual ao esperado

Podemos utilizar diferentes headers, sessions, e métodos HTTP para testar nossos comportamentos! Então os testes de requests estão focados no comportamento a partir de um modelo de requisição recebida.

Para testarmos requests, as ferramentas de testes nos fornecem funções como:

E objetos como:

Respondendo nossas perguntas:

Image for post
Image for post

R: Sim e não. Um teste de feature não garante a funcionalidade total de uma view. O teste de feature garante o comportamento de uma funcionalidade no nosso sistema como um todo. Ocasionalmente um teste de feature pode disparar um erro por conta de problema em uma view.

R: Sim.

R: Funcionalidade do sistema.

R: Não, um teste de request é focado no comportamento a partir de um modelo de requisição recebida.

R: Nesse caso, sim, dado que as funcionalidades de uma API se baseiam em cima de requisições. Não temos um usuário final utilizando uma API. A sua tia não vai fazer uma compra online na americanas.com enviando um POST para a API deles. Toda interação com uma API é a partir de Requests.

Não deixe de testar!

Escrever testes é de suma importância, principalmente se temos um projeto complexo e cheio de regras de negócio. É uma maneira de garantir que o sistema funcionará quase que perfeitamente independente de qualquer futura alteração. Além disso, um projeto sem testes automatizados requer que testemos manualmente todas as funcionalidades cada vez que um código novo for adicionado. Coisa que muita gente não faz, resultando embugs e problemas escondidos no sistema, o que vira uma “bola de neve”.

Escrever testes é garantir qualidade, e também garantir que teremos muito menos problemas no futuro.

Se não testarmos o projeto que estamos desenvolvendo, seremos testados (através da nossa paciência)


true |> henrique

/truehenrique.com/ Artigos sobre Elixir, Ruby, carreira e desenvolvimento web.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store