TESTES

TESTES

1. Código sem testes é um código ruim. – Michael Feathers.

2. Para evitar que tais erros cheguem aos usuários finais e causem prejuízos de valor incalculável, é fundamental introduzir atividades de teste em projetos de desenvolvimento de software.

3. TESTES MANUAIS

   • Dão muito trabalho, são demorados e caros. Pior ainda, eles devem ser repetidos toda vez que o sistema sofrer uma modificação.

4. TESTES AUTOMATIZADOS

   • Processo no qual as ferramentas de software executam testes pré-programados em um aplicativo de software antes de serem liberados para produção.

5. PIRÂMIDE DE TESTES

   • TESTES DE UNIDADE
     • Verificam automaticamente pequenas partes de um código, normalmente uma classe apenas.
       • São simples, mais fáceis de implementar e executam rapidamente.
   • TESTES DE INTEGRAÇÃO
     • Também chamado de testes de serviço
       • Exercitam um serviço completo, isto é, uma funcionalidade de maior granularidade do sistema.
     • Eles envolvem mais classes, às vezes de pacotes distintos.
       • Como são testes maiores, eles levam mais tempo para executar e, consequentemente, são chamados com menor frequência.
         • Também envolvem dependências e sistemas reais, como bancos de dados e serviços remotos
   • São testes automatizados de pequenas unidades de código, normalmente classes, as quais são testadas de forma isolada do restante do sistema.
     • Quando se usa testes de unidades, o código de um sistema pode ser dividido em dois grupos: um conjunto de classes — que implementam os requisitos do sistema — e um conjunto de testes
       • São implementados usando-se frameworks construídos especificamente para esse fim
         • Teste: método que implementa um teste.
         • Fixture: estado do sistema que será testado por um ou mais métodos de teste, incluindo dados, objetos, etc.
         • Casos de Teste (Test Case): classe com os métodos de teste.
         • Suíte de Testes (Test Suite): conjunto de casos de teste, os quais são executados pelo framework de testes de unidade (que no nosso caso é o JUnit).
         • Sistema sob Teste (System Under Test, SUT): sistema que está sendo testado.
         • Primeiro, pode-se escrever os testes após implementar uma pequena funcionalidade.
           • Isto é, pode-se programar um pouco e escrever testes
         • Pode-se escrever os testes primeiro, antes de qualquer código de produção.
         • PRINCÍPIOS E SMELLS
           • Princípios FIRST
             • Rápidos (Fast): desenvolvedores devem executar testes de unidades frequentemente, para obter feedback rápido sobre bugs e regressões no código.
             • Independentes: a ordem de execução dos testes de unidade não é importante.
             • Determinísticos (Repeatable): testes de unidade devem ter sempre o mesmo resultado.
             • Auto-verificáveis (Self-checking): O resultado de um teste de unidades deve ser facilmente verificável.
             • Escritos o quanto antes (Timely), se possível antes mesmo do código que vai ser testado
           • Test Smells
             • Test Smells representam estruturas e características preocupantes no código de testes de unidade, as quais, a princípio deveriam ser evitadas.
               • Um Teste Obscuro é um teste longo, complexo e difícil de entender
               • Um Teste com Lógica Condicional inclui código que pode ou não ser executado.
               • Duplicação de Código em Testes ocorre, como o próprio nome sugere, quando temos código repetido em diversos métodos de teste.
           • Cobertura de Testes
             • Cobertura de testes é uma métrica que ajuda a definir o número de testes que precisamos escrever para um programa. Ela mede o percentual de comandos de um programa que são cobertos por testes.
               • Cobertura de testes = (número de comandos executados pelos testes) / (total de comandos do programa).
     • Correspondência entre classes e testes
   • TESTES DE SISTEMA
     • Estão posicionados no topo da pirâmide de testes.
       • São os testes mais caros, que demandam maior esforço para implementação e que executam em mais tempo.
         • Além disso, o teste deve tratar eventos de interfaces, como timeouts que ocorrem quando uma página demora mais tempo do que o usual para ser carregada.
     • Trata-se de testes que simulam o uso de um sistema por um usuário real.
       • São também chamados de testes ponta-a-ponta (end-to-end) ou então testes de interfaces.
         • Testes de interface também são mais frágeis, isto é, eles podem quebrar devido a pequenas mudanças na interface.

6. TESTES DE CAIXA-PRETA E CAIXA-BRANCA

   • Quando se usa uma técnica caixa-preta, os testes são escritos com base apenas na interface do sistema sob testes.
   • Por outro lado, quando se usa uma técnica caixa-branca, a escrita dos testes considera informações sobre o código e a estrutura do sistema sob teste.

7. TESTES DE ACEITAÇÃO

   • São testes realizados pelo cliente, com dados do cliente. Os resultados desses testes irão determinar se o cliente está de acordo ou não com a implementação realizada.
     • Primeiro, são testes manuais, realizados pelos clientes finais do sistema.
     • Testes alfa são realizados com alguns usuários, mas em um ambiente controlado, como a própria máquina do desenvolvedor
     • Se o sistema for aprovado nos testes alfa, pode-se realizar um teste com um grupo maior de usuários e não mais em um ambiente controlado. Esses testes são chamados de testes beta.

Imágenes y archivos del mapa