[Ruby] Testando Features, Views e Requests

Henrique Fernandez
Jul 16, 2018 · 7 min read

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:

  • Quando testamos features, também estamos testando views?
  • Preciso de testes de view se tenho testes de feature?
  • O que significa feature?
  • Requests também retornam views, logo, se eu testo o retorno de requests também estou testando views?
  • Um teste de feature de uma API é a mesma coisa que um teste de request?

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! 😄

  • JUnit - Java
  • PHPUnit - Php
  • Jasmine - Javascript
  • EXunit - Elixir
  • Hspec - Haskell

Testando Features

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 é:

  • Sacar dinheiro
  • Realizar depósitos
  • Pagar boletos
  • Ver extrato da conta

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:

  • Temos um teste automatizado
  • Estamos simulando(literalmente) a interação de um usuário “pagando uma conta” através do sistema!

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:

  • visit (visite a página)
  • click_button (clique em um botão)
  • fill_in (preencha este campo)
  • click_link (clique neste link)

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

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:

  • assign (associe esse dado à esta variavel na view)
  • render (renderize a view)
  • rendered (a página renderizada)

Testando Requests

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:

  • Uma requisição pode ser composta por sessions, cookies e headers.
  • Pode ser realizada através de diversos métodos como post, get, put e delete
  • Pode conter diversos tipos de respostas: 200 Success, 201 created, 404 Not Found, 403 Unauthorized e etc..

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:

  • get (envia requisições GET para um endpoint)
  • post (envia requisições POST para um endpoint)
  • put (envia requisições PUT para um endpoint)
  • delete (envia requisições DELETE para um endpoint)

E objetos como:

  • response (contendo o conteúdo respondido pela sua aplicação a partir da requisição)

Respondendo nossas perguntas:

  • Quando testamos features, também estamos testando views?

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.

  • Preciso de testes de view se tenho testes de feature?

R: Sim.

  • O que significa feature?

R: Funcionalidade do sistema.

  • Requests também retornam views, logo, se eu testo o retorno de requests também estou testando views?

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

  • Um teste de feature de uma API é a mesma coisa que um teste de request?

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.

Medium is an open platform where 170 million readers come to find insightful and dynamic thinking. Here, expert and undiscovered voices alike dive into the heart of any topic and bring new ideas to the surface. Learn more

Follow the writers, publications, and topics that matter to you, and you’ll see them on your homepage and in your inbox. Explore

If you have a story to tell, knowledge to share, or a perspective to offer — welcome home. It’s easy and free to post your thinking on any topic. Write on Medium

Get the Medium app

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