Por que é testabilidade?
À primeira vista, o engenheiro de teste típico já tem coisas suficientes para fazer:
- Elabore os requisitos.
- Crie planos e estratégias.
- Escreva casos de teste.
- Reporte e verifique novamente os bugs.
- TESTE!
Em algum lugar entre essas coisas, você ainda precisa encontrar tempo para a automação. E você ainda precisa fazer uma demonstração para o cliente.
Por que se preocupar com essa testabilidade ?
Não é essa a tarefa de quem escreve este código? É possível que um engenheiro de teste influencie a equipe (especialmente os arquitetos e desenvolvedores) – e torne o software um pouco mais aberto e fácil de testar?
Vamos tentar descobrir isso um pouco juntos.
Testabilidade: oficialmente e nem tanto
Qual é a definição de testabilidade dada pelos padrões da indústria?
De acordo com a ISO/IEC 25010:2011 : Testabilidade – grau de eficácia e eficiência com que os critérios de teste podem ser estabelecidos para um sistema, produto ou componente, e os testes podem ser realizados para determinar se esses critérios foram atendidos.
De acordo com a terminologia ISTQB : Testabilidade – A capacidade do produto de software para permitir que o software modificado seja testado.
Em termos simples, testabilidade é o quão conveniente e fácil é testar um componente individual e todo o sistema.
A testabilidade depende de vários fatores:
- Quão fácil é controlar o estado interno dos componentes durante o teste?
- É difícil observar o sistema e seus componentes durante os testes?
- É possível testar componentes isoladamente?
- Quão totalmente documentado é o componente?
- É possível escrever testes automatizados para ele?
Testabilidade no nível do código
Para testar classes com eficiência no nível do módulo, você precisa ser capaz de criar objetos Mock para todas as dependências de classe.
Se o desenvolvedor aplicar o princípio de inversão de dependência , haverá significativamente menos problemas de teste. Idealmente, você precisa passar todas as dependências pelo construtor da classe.
Além disso, não se esqueça da observabilidade e controlabilidade , mesmo no nível da classe. O desenvolvedor (ou engenheiro de teste) deve ser capaz de ver o estado das partes críticas do objeto a qualquer momento. Seria muito melhor adicionar métodos diferentes para obter essas informações diretamente para a classe de teste.
Mas ainda assim – esse aspecto é inteiramente de responsabilidade do desenvolvedor.
Testabilidade no nível da arquitetura
Uma dica prática no nível da arquitetura seria separar a infraestrutura e o código de domínio . Por código de domínio, entendemos todo o código responsável pela lógica de negócios. O código de infraestrutura funciona com dependências externas – bancos de dados, filas de mensagens, serviços de terceiros etc.
Para separar um tipo de código de outro, você pode projetar componentes usando o padrão Portas e Adaptadores (Hexagonal) . Alistair Cockburn propôs este modelo em 2005.
Testabilidade através dos olhos dos testadores
Ok, mas como um engenheiro de teste específico pode afetar a testabilidade?
Propriedades únicas dos elementos
Se você escreveu mais de um teste de interface do usuário, pode dizer muito sobre a dor dos localizadores “longos e frágeis”. A alteração dos elementos na página é um dos principais motivos da instabilidade de tais testes.
Como engenheiro de teste, você pode fazer duas coisas neste caso para melhorar a testabilidade:
- Concorde com a equipe (ou arquitetos) para adicionar propriedades exclusivas para cada novo elemento crítico;
- Concorde com os desenvolvedores que você adicionará propriedades exclusivas aos elementos sempre que for necessário (para componentes legados);
Ter uma propriedade especial como “automation-id” ou “data-id” para um elemento da web economiza tempo e nervos para um engenheiro de teste.
Componentes em isolamento
Acompanhe a conveniência de testar o componente isoladamente. Idealmente, um desenvolvedor ou testador deve isolar uma única parte (por exemplo, um único microsserviço) e testar apenas a lógica de negócios.
- É fácil substituir o banco de dados real por um na memória?
- É conveniente preencher o banco de dados com os dados de teste necessários para a operação correta do componente?
- É fácil bloquear solicitações externas para serviços de terceiros?
- É difícil enviar ou ler mensagens na fila de mensagens para um único serviço?
Você sempre pode trabalhar em conjunto com um desenvolvedor para construir essas ferramentas para os componentes do seu sistema. Em muitos casos, essas ferramentas podem ser encontradas como bibliotecas. Se não – é um bom ponto para criá-lo e difundir como fonte interna na organização.
API para gerenciamento do sistema
É bom analisar como você testa (de vez em quando). Alguns componentes do sistema podem funcionar usando probabilidades ou dados específicos de terceiros. Os testes para esses componentes serão instáveis. Mas esses sistemas devem ser testados e, idealmente, automatizados também.
Em busca das respostas, podemos pensar nele como um sistema de saves em um jogo de computador. Imagine que você precisa testar como o “chefe” se comporta no final do nível. Você pode verificá-lo jogando todo o nível desde o início até o fim. Se falarmos de um ou dois minutos – está tudo bem. Mas se cada nível do jogo levar dez minutos ou mais – esses testes rapidamente se tornam irrealisticamente longos.
Uma maneira melhor será usar magic save, chegar ao final do nível e testar o comportamento exato.
A solução é fazer uma API de teste separada que permitirá trazer o sistema para um ou outro estado. O uso dessa API tornará os testes mais rápidos e aumentará a estabilidade e a previsibilidade do sistema em teste (em um determinado nível).
Essa é a razão pela qual muitos jogos têm uma longa lista de códigos de trapaça.
Você pode pensar em tal sistema de “trapaça” no contexto de sua aplicação. Podem ser comandos especiais que você precisa inserir ou formas separadas de criar dados que o sistema processará como teste (mesmo em produção). Esses dados serão mais fáceis de filtrar e analisar.