Engenharia de Software Cap. 8: Testes

Engenharia de Software Cap. 8: Testes

1. "Code without tests is bad code." – Michael Feathers

2. O desenvolvedor que implementa uma classe também deve implementar os seus testes

3. Programas tornaram-se auto-testáveis

4. Testes automatizados

   • Pirâmide de testes
     • Proposta por Mike Cohn
     • Particiona os testes de acordo com sua granularidade
     • Testes de unidade
       • Verificam automaticamente pequenas partes de um código, normalmente uma classe apenas
       • O código pode ser dividido em dois grupos
         • Conjunto de classes
         • Conjunto de testes
       • São implementados usando-se frameworks
         • sUnit
           • Implementado por Kent Beck no final da década de 80 para Smalltalk
         • JUnit
           • Implementada por Kent Beck e Erich Gamma, em 1997
           • Permite implementar classes que vão testar — de forma automática
           • Métodos de teste
             • 1º - Fixture
               • Cria-se o contexto do teste, instancia os objetos que se pretende testar e, se for o caso, inicializá-los
               • Criação uma pilha de nome stack
               • 2º - Chamar um dos métodos da classe
                 • 3º - Assert
                   • Testa se um determinado resultado é igual a um valor esperado
                   • Deve existir no máximo um assert por teste
                   • Não se recomenda usar dois comandos assert no mesmo método
                     • Excessões
                       • Se uma função retorna vários campos de um objeto, é justificável ter um assert para cada um dos campos
                       • Quando temos um método simples, que pode ser testado por meio de um único assert
           • Para cada classe de teste, ele chama de @Test
             • antes de chamar um método @Test, o JUnit instancia um objeto da sua classe
       • Quando escrever testes de unidade?
         • Após implementar uma pequena funcionalidade
         • Antes de qualquer código de produção
         • Quando um usuário reportar um bug
         • Quando se estiver depurando um trecho de código
         • Não é recomendável é deixar para implementar todos os testes após o sistema ficar pronto e nem que eles sejam feitos por outro time ou empresa
     • Testes de integração (testes de serviços)
       • Verificam uma funcionalidade ou transação completa de um sistema
       • Usam diversas classes, de pacotes distintos, podem ainda testar componentes externos
     • Testes de sistema (testes de interface com o usuário)
       • Simulam uma sessão de uso do sistema por um usuário real
       • São testes de ponta a ponta (end-to-end)

5. 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
       • Se ocorrer de não ser determinístico é chamado de
         • Testes Flaky (Testes Erráticos)
           • Testes flaky são ruins porque eles atrasam o desenvolvimento
     • Auto-verificáveis (Self-checking)
       • O resultado de um teste de unidades deve ser facilmente verificável seja em falha ou acerto.
     • Escritos o quanto antes (Timely)
       • Se possível antes mesmo do código que vai ser testado
   • Test Smells
     • Estruturas e características preocupantes no código de testes de unidade que deveriam ser evitadas
     • Teste Obscuro
       • É um teste longo, complexo e difícil de entender
     • Teste com Lógica Condicional
       • São testes com comandos if ou laços, não é a forma ideal de se realizar testes de unidade
     • Duplicação de Código em Testes

6. Cobertura de Testes

   • Cobertura de testes = (número de comandos executados pelos testes) / (total de comandos do programa)
   • Existem ferramentas para cálculo de cobertura de testes
     • Ferramentas de cobertura de testes em java trabalham instrumentando os bytecodes gerados pelo compilador da linguagem.
   • Cobertura de testes ideal?
     • Varia, dependendo da complexidade dos requisitos, da criticidade do projeto, etc.
     • Deve-se monitorar a evolução dos valores de cobertura ao longo do tempo
   • Outras definições
     • Cobertura de funções
       • Percentual de funções que são executadas por um teste
     • Cobertura de chamadas de funções
       • De todas as linhas de um programa que chamam funções, quantas são, exercitadas por testes
     • Cobertura de branches (Cobertura C0 ou Cobertura C1)
       • % de branches de um programa que são executados por testes

7. Testabilidade

   • É uma medida de quão fácil é implementar testes para um sistema
   • Servlet
     • É uma tecnologia de Java para implementação de páginas Web dinâmicas
     • Implementa uma função IMCServlet
   • Chamada Assíncrona
     • Implementa uma função asyncPI
       • Em um código apenas essa função seria testada por um teste de unidade

8. Mocks

   • É uma solução que consiste em criar um objeto que emula o objeto real, mas apenas para permitir o teste do programa.
   • Frameworks de Mocks
     • mockito
       • Facilita a criação de mocks
       • Dispensa a implementação de um mock "manual".
   • Objetos dublê
     • Objetos Dummy
       • São objetos que são passados como argumento para um método, mas que não são usados.
     • Objeto Fake
       • São objetos que possuem uma implementação mais simples do que o objeto real.

9. Desenvolvimento Dirigido por Testes (TDD)

   • Dado um teste de unidade T para uma classe C, TDD defende que T deve ser escrito antes de C.
   • Ajuda a evitar que os desenvolvedores esqueçam de escrever testes
   • Favorece a escrita de código com alta testabilidade
     • 1 - Estado vermelho: teste não está passando
       • Ao falhar o desenvolvedor pelo menos tem em mãos uma especificação da classe que ele precisará implementar em seguida.
   • É uma prática relacionada não apenas com testes, mas também com a melhoria do design de um sistema
   • 11 - Estado verde
     • Deve-se implementar a funcionalidade completa da classe sob teste
   • 111 - Refatoração
     • Deve-se verificar a possibilidade de melhorar a qualidade do projeto do código

10. Teste de Integração

    • Exercitam um serviço completo, envolvendo mais classes, as vezes de pacotes distintos, banco de dados e sistemas remotos

11. Testes de Sistema

    • Trata-se de testes que simulam o uso de um sistema por um usuário real
    • São os testes mais caros, tem maior esforço e demoram mais tempo
    • Também chamados de :
      • Ponta-a-Ponta (end-to-end)
      • Testes de interfaces

12. Testes Caixa-Preta e Caixa-Branca

    • Técnica caixa-preta (Testes funcionais)
      • Os testes são escritos com base apenas na interface do sistema sob testes
      • Seleção de Dados de Teste
        • Classe de Equivalência
          • É uma técnica que recomenda dividir as entradas de um problema em conjuntos de valores que têm a mesma chance de apresentar um bug
          • Para cada classe de equivalência,testa-se apenas um dos seus valores, que pode ser escolhido randomicamente
        • Análise de Valor Limite (Boundary Value Analysis)
          • É uma técnica que recomenda testar uma unidade com os valores limites de cada classe de equivalência e seus valores subsequentes (ou antecedentes).
    • Técnica caixa-branca (Testes estruturais)
      • A escrita dos testes considera informações sobre o código e a estrutura do sistema sob teste

13. Testes de Aceitação

    • São testes realizados pelo cliente, com dados do cliente
    • Vão determinar se o cliente está de acordo ou não com a implemetação efeturada
    • Testes manuais
      • São realizados pelos clientes finais
    • Não é constituido como uma atividade de verificação mas, de validação
    • Testes alfa
      • São realizados com alguns usuários, mas em um ambiente controlado, como a própria máquina do desenvolvedor.
    • Testes beta
      • São realizados um grupo maior de usuários e não mais em um ambiente controlado

Images and files in the map