Tipos de testes automatizados

Olá!
Enquanto escrevia a introdução sobre automação, notei que não existia nenhum post falando sobre os tipos de testes automatizados =/
Quando falamos de testes automatizados aqui no blog, normalmente estamos falando de testes de aceitação (e2e – End to End), mas existem outros tipos de testes que também são importantes, mesmo que não sejamos nós que iremos faze-los, é bom conhece-los
É um post mais com o intuito de contextualizar, mas não deixa de ser importante 🙂


Teste unitário

É um teste que normalmente é feito pelo próprio dev, um teste bem rápido que não vai simular um usuário nem nada do gênero.

O teste é focado em um módulo apenas , ou seja vai ignorar as integrações desse módulo É comum até mesmo “mockar” as integrações de outros módulos,ao invés de fazer as integrações, pois se tiver algum erro em outro módulo não vai interferir nos testes unitários desse módulo.

“Mockar” é simular no código que aquela informação já foi passada para o módulo vindo por outra parte do sistema, vou dar um exemplo:

Digamos que temos uma aplicação onde o usuário se loga e pode fazer diversas coisas, entre elas enviar um e-mail, e esse e-mail já é enviado com uma assinatura automática com as informações do meu perfil (nome, sobrenome, e-mail).
Eu tenho um módulo no sistema que deve gerar e enviar esse e-mail, então esse módulo vai receber as informações salvas no banco de dados(nome, sobrenome, e-mail) e adicionar elas na assinatura, no teste unitário, ao invés de pegar os dados no banco, vou simular mockar as informações, dizendo no código do meu teste com o que cada campo foi preenchido:

campo nome = ‘nome’
campo sobrenome = ‘sobrenome’
email = ‘teste@mail.com’

Então, mesmo que a tela de perfil esteja com erro e esteja salvando dados inválidos no banco, meus testes não vão falhar, pois estou testando apenas o módulo do e-mail.

Se a tela de perfil salvar dados errados não conseguir enviar o e-mail, esse erro deve ser notado em outro teste, mas com esse teste unitário já sabemos que não é o e-mail que está com o problema, logo podemos ir ver como a tela de perfil está salvando os dados no banco, já é um caminho para analisar o erro.

Teste de integração

Também costuma ser um teste feito pelo Dev, como o próprio nome diz, ele testa a integração entre módulos, normalmente esse teste é feito quando existem módulos externos interagindo com módulos internos, um exemplo bom pra isso é o do banco de dados, vou aproveitar o exemplo anterior pra explicar.

Os testes de integração vão verificar se o banco de dados está recebendo as informações que a tela de perfil está mandando e se depois está enviando os dados corretos para o e-mail. Então se a tela de perfil está enviando:

Nome = Diego

Sobrenome = blond

E-mail = meunomecompletodebatismo@hotmail.com

mas o banco de dados está recebendo:

Nome = meunomecompletodebatismo@hotmail.com

Sobrenome = blond

E-mail = null

É no teste de integração que podemos perceber isso, ou seja, com testes unitários e de integração conseguimos ter uma boa cobertura dos cenários de teste e pegar vários erros antes de começar os testes mais complexos, e como disse anteriormente, são testes que não simulam o usuário, são testes bem mais rápidos, então tem essa vantagem de poder executar mais vezes sem gastar tanto tempo assim

 

Então só reforçando, com o teste unitário focamos apenas no módulo, testando ele de forma isolada e evitando dependências externas, e para garantir que essas integrações estão se comunicando corretamente, você faz o teste de integração, pois ele não vai testar os módulos em si, mas exatamente essa parte da comunicação entre eles.
Os dois testes se completam s2

Teste de aceitação

Chegamos ao teste que a maioria de nós conhecemos, o nosso querido e2e!

Esse teste é mais demorado que os anteriores, por que ele simula que existe um usuário utilizando o sistema, então ele tem as limitações de esperar a tela carregar, preencher os campos e por aí vai, ainda é mais rápido que um teste manual, mas ainda leva um tempo para rodar todos os testes.

Existem diversas ferramentas e formas de realizarmos esses testes, por exemplo selenium e o protractor, o desenvolvimento altera de acordo com a ferramenta utilizada, não vou entrar muito nos detalhes sobre esses testes por que está saindo uma série de posts sobre o protractor, e tenho um post de testes manuais x testes automatizados, que na verdade foi escrito considerando mais os testes de aceitação do que os anteriores 🙂

Teste de mutação

Não conheço tanto dele, mas o pouco que conheço já me convenceu de que é uma sensacional (s2)
É um teste trabalhoso, lento e caro.
Mas é assim…… ele vai testar toda sua cobertura de testes da seguinte forma:
Ele vai mudar 1 detalhe do seu código, tipo um sinal em uma conta invertido, ou o nome de uma classe, e vai rodar todos seus testes pra ver o que falha (e um teste pelo menos tem que falhar né?), depois ele vai reverter o código para o original e mudar outro detalhe, e rodar todos os testes de novo. Sim ele vai fazer isso MUITAS vezes pra ver se seus testes unitários/integração estão realmente testando o sistema inteiro, se ele mudar um detalhe e nenhum teste falha….temos um problema .

Não quero usar palavrões no blog…então vou comentar apenas “DAHORA NÉ?!”

PLOT TWIST

Então, só pra constar… eu falei que testes unitários e de integração normalmente são responsabilidade dos devs, mas queria deixar registrado que quanto mais entendermos desses testes, melhor vai ser. Podemos sim fazer esses testes quando for necessário e agradar ao time 😉

 

 

Anúncios

Um comentário sobre “Tipos de testes automatizados

Deixe um comentário

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s