Testes: existe vida antes do TDD
Diana Ungaro Arnos
Objetivos
● Entender o que são testes de software;
● Entender a importância dos testes unitários
no desenvolvimento de software;
● Proporcionar uma visão geral sobre vários
tipos de teste.
Agenda
● Testes: por que, o que são e tipos;
● Testes automatizados e Continuous Integration;
● Testes unitários e mocking;
● Testes funcionais e de aceitação;
● Testes de estresse.
Testes: por que, o que são e tipos
Testes: por que, o que são e tipos● Garantir que a aplicação faça a coisa certa do jeito
certo (Uncle Bob)
● Procurar e encontrar bugs
● Evitam perda de dinheiro e comprometimento da
imagem da empresa
● Podem ser caixa branca ou caixa pretaCom verificação de código
O código não interessa
Testes: por que, o que são e tiposTipos
Unitário
Testam unidades individuais de código, como
classes e métodos
Integração
Testam partes da aplicação e sua integração com o
resto do sistema (teste de componentes). Identifica erros de interface entre
módulos.
Sistema
São testes tipo caixa preta que analisam a aplicação
ponta-a-ponta,baseados nos requisitos de sistema. Seguem roteiros, definidos de acordo com
planos de teste pré definidosCaixa branca
Testes automatizados e CIAutomatização de testes● Utilização de software especializado que controla a execução de
testes e a comparação de resultados previstos e esperados;
Continuous Integration● Prática de engenharia de software em que mudanças no código são
imediatamente testadas e reportadas quando adicionadas a umabase de código (quando é feito um pull request)
Testes automatizados e CI
O cenário ideal
1. Pull request feito2. Execução automática dos testes
disponíveis3. É gerado um relatório com o
resultado dos testes e a indicação se as alterações podem ser integradas ao código sem problemas
Testes automatizados e CI
O cenário OMFG! *_*
Todos os passos anteriores e mais:
4. Após a execução com sucesso dos testes, o código é automaticamente integrado (merge)
5. O relatório gerado indica todas as alterações que foram adicionadas ao código (diff)
Obs.: O teste de sistema sempre terá uma parte manual, mas também pode (e deve) ser complementado com testes automatizados que cobrem vários cenários
Testes automatizados e CIBoas práticas de Continuous Integration● Comitar código frequentemente;● Categorizar os testes;● Utilizar um servidor integrado de build;● Utilizar mecanismos de feedback contínuo;● Builds de staging.
Testes unitários e mockingObjetivo: garantir o retorno esperado em todos os casos possíveis
O Caminho Feliz Fluxo Alternativo Fluxo de Exceção
Não testam lógica de negócio, apenas a implementação do código
Testes unitários e mocking
Vantagens!● Manutenção facilitada de código
● Segurança ao refatorar
● Serve como documentação
● Estimula melhor implementação
da programação orientada a
objetosSai mais barato descobrir um bug em estágios iniciais de desenvolvimento
Testes unitários e mockingSeu teste está errado quando:
● Você precisa alterar seu ambiente para os testes rodarem sem problemas
(ex.: alterar configurações da aplicação)
● Faz comunicação com algum banco de dados
● Utiliza algum recurso de rede
● Utiliza seu sistema de arquivos
Testes unitários e mockingBoas práticas!
● Cada teste verifica apenas um comportamento
● Um teste não deve depender do resultado de outro
● Testar apenas métodos públicos
● O nome de cada teste deve indicar o que está sendo testado e qual o resultado esperado (sim,
algunsNomesPodemFicarUmTantoGrandes)
● Usar testes parametrizados sempre que possível
Polêmica: usar um único método de assert por teste
Testes unitários e mockingMockingCriação de objetos que simulam o comportamento de objetos reais e substituem as dependências externas nos testes.
Stubs
Não têm lógica, apenas retornam o que você
mandar, basicamente com reusultados hard coded
Fakes
Mais próximos da implementação de objetos
reais, possuem lógica e são capazes de manter um
estado
Mocks
Objetos baseados em expectativas e que simulam
comportamento, testam interações entre objetos
Testes funcionais e de aceitação
Funcionais
São testes de verificação e descrevem o que o sistema faz,
analisando as saídas de acordo com as entradas, baseados nas
especificações de negócio. Por exemplo: teste de cálculo de frete.
Aceitação
São testes de validação. Verificam se a aplicação satisfaz as necessidades
do cliente. É a última camada de testes, muitas vezes executada quando a aplicação já está em
produção. Por exemplo: teste AB.
Testes Caixa Preta
Testes de estresseVerificam robustez, disponibilidade e resiliência da aplicação quando está sob condições desfavoráveis
● Não-funcionais;● Caixa branca ou preta;● De acordo com a definição pen testing e fuzz testing também pode ser
considerados testes de estresse.
DÚVIDAS?
Obrigada!
Diana Ungaro Arnos
Webdev @ Tricae
Twitter: @dianaarnos
G+: +DianaUngaroArnos
Facebook: /dianaaarnos