Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Season - Testes: Existe Vida Antes do TDD

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.

Diana Arnos

December 16, 2014
Tweet

More Decks by Diana Arnos

Other Decks in Programming

Transcript

  1. 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.
  2. 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.
  3. 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
  4. 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
  5. 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)
  6. 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
  7. 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
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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.