Em uma discussão recente no Yahoo! Grupo de test driven development Carlos Ble compartilhou seu entendimento de categorias de testes decorrente de sua pesquisa:
Acabei tendo a seguinte imagem:
Testes do desenvolvedor:
Testes unitários : Isolados, atômicos, inócuos: exercitados com xUnit
Testes de integração:
Testes isolados que podem mudar o estado do sistema, por exemplo: salvar em banco, escrever em arquivo... Um teste de integração não representa por si um requisito funcional. Podem ser escritos para xUnit. Eles verificam a integração do nosso código com uma ferramenta de terceiros ou com diferentes camadas de nosso próprio código, por exemplo: a camada de lógica de negócio requer a camada de acesso a dados
Testes funcionais: (também conhecidos como Testes de Sistema)
Um teste que exercita uma parte completa do sistema, algum requisito funcional. Ele pode mudar o status do sistema.
Testes do Product Owner:
Testes de aceitação: Testes funcionais cuja entrada e saída podem ser validadas por uma pessoa não-técnica, o product owner.
John Donaldson forneceu um modelo multidimensional para testes que foca em papéis de teste e tipos de teste:
Eu gosto da visão de testes que você propõe. Mas acho que é uma instância de um modelo maior, onde você tem (pelo menos) papéis de atuação e tipos de teste.
Papéis de atuação: desenvolvedor, testador, QA, usuário, sponsor, etc.
Tipos de teste: unitários, de integração, funcionais, sistêmicos, de aceitação, de carga prolongados (soak), preliminares (smoke), etc.
Em qualquer situação dada você provavelmente sabe qual papel se encarrega de qual teste - mas no próximo projeto isso pode ser diferente.
Dale Emery sugeriu que não saber qual tipo de teste você está escrevendo é um sintoma de código ruim e indica falta de clareza. Um teste pode cair em diversas categorias ao mesmo tempo e o que importa é o seu ponto de vista atual:
O desafio, penso eu, é que qualquer teste pode ser classificado razoavelmente de várias formas diferentes, dependendo de quais dimensões você está focando. E existem diversas dimensões que as pessoas usam para classificar testes. Eu identifiquei algumas aqui: http://cwd.dhemery.com/2004/04/dimensions/
Por isso estou menos interessado em saber "qual tipo" de teste é, e mais interessado em saber onde um teste se encaixa nas dimensões que são mais importantes para mim, dependendo do meu objetivo em determinado momento. Aquelas em que penso com mais frequência são:
- Qual "unidade" esse teste define e valida? (Qual sistema, subsistema, objeto, colaboração...) - Qual funcionalidade o teste define e valida?
- Quem está primariamente envolvido com esse teste? Quem se preocupa mais com os resultados da execução desse teste?
- Quais decisões serão tomadas a partir dos resultados da execução desse teste?
Charlie Poole fornece uma análise detalhada da categorização de Carlos e sugere:
Na minha opinião, a distinção mais importante é entre os testes de objetivos do desenvolvedor e os testes de objetivos do cliente.
Essa discussão evidencia o fato de que classificar testes pode ser bastante confuso - especialmente para o iniciante. O consenso é que a forma mais indicada para classificar testes é uma abordagem dimensional e que o tipo de classificação que é relevante depende dos objetivos do usuário naquele momento e do contexto.