Season - Testes: Existe Vida Antes do TDD

Teste de software: descrição dos diferentes tipos, com enfoque em testes unitários, apresentando boas práticas e o que deve ser evitado.

Transcript

1. Testes: existe vida antes do TDD Diana Ungaro Arnos
2. 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.
3. 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.
4. Testes: por que, o que são e tipos
5. 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 preta Com verificação de código O código não interessa
6. Testes: por que, o que são e tipos Tipos 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é definidos Caixa branca
7. Testes automatizados e CI Automatizaçã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 uma base de código (quando é feito um pull request)
8. Testes automatizados e CI O cenário ideal 1. Pull request feito 2. Execução automática dos testes disponíveis 3. É 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
9. 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
10. Testes automatizados e CI Boas 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.
11. Testes unitários e mocking Objetivo: 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
12. 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 objetos Sai mais barato descobrir um bug em estágios iniciais de desenvolvimento
13. Testes unitários e mocking Seu 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
14. Testes unitários e mocking Boas 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
15. Testes unitários e mocking Mocking Criaçã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
16. 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
17. Testes de estresse Verificam 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.
18. DÚVIDAS?
19. Obrigada! Diana Ungaro Arnos Webdev @ Tricae Twitter: @dianaarnos G+: +DianaUngaroArnos Facebook: /dianaaarnos