| title | published | description | tags | canonical_url | cover_image | series |
|---|---|---|---|---|---|---|
QA, trate sua automação como software |
true |
testing, testautomation, ptbr |
Quando pensamos em automação de testes, muitas vezes passa pela nossa cabeça questões como pirâmide de testes e qual linguagem/framework será utilizado para realizar a automação. Caso seja levado em conta boas práticas de automação, não passamos da discussão de adotar page objects ou page actions na automação de interface.
Porém, é importante atentarmos que há muitos outros fatores determinantes para a manutenção daquela automação por membros da equipe, afinal, quem nunca trocou trechos de código via chat ou teve dificuldade para saber porque que uma determinada alteração foi realizada na automação?
É importante preocuparmos mais com o nosso código, afinal...
E vamos ser sinceros, assim como o dev deve entregar seu código com qualidade, nada mais justo que nós, QA, também entreguemos com qualidade.
Esses problemas foram solucionados há muito tempo no desenvolvimento de software e pretendo listar aqui algumas dicas interessantes de serem adotadas no seu código de automação software.
Resumo:
- Utilize Git e deixe o código acessível
- Escreva boas mensagens de commit (caso já utilize git)
- Padronize o seu código
- Documente o seu projeto
- Separe as dependências de desenvolvimento e produção
Versione o seu código utilizando Git e o torne acessível para os outros membros através de conta no Gitlab, Github ou hospedado em servidor da empresa. Com isso, pare de:
- Hospedar o código apenas na sua máquina (ela pode pifar).
- De manter código comentado, por ter medo de que aquele trecho de código será necessário um dia (nunca será).
- E, principalmente, de enviar arquivos via e-mail e tendo sempre que fazer o controle de qual arquivo pode ser substituído ou não.
Deixe tudo isso para o git resolver.
Para saber mais, veja as dicas de git para testers.
Bônus:
- Use branch.
- Evite usar GitFlow. Para saber mais leia Git Flow vs Github Flow e GitFlow considered harmful.
- Use
rebase, evite de usarmerge.
Agora que está utilizando o git, é importante que não cometa as falhas de escrita de mensagens de commit. É comum clonarmos um repositório de testes, tentarmos investigar porque tal arquivo foi modificado e depararmos com um log nada amigável como esse:
Sim, esse log é real
Vendo esse log, consegue identificar de forma fácil o motivo de cada alteração? Para saber terá que investigar as alterações realizadas ou conversar com o autor do código, que pode nem estar mais na empresa. E tudo isso vai te fazer gastar um bom tempo.
É importante que as mensagens de commit sejam totalmente claras, de forma de que ao lê-la fique claro que tipo de alteração foi feita e o que levou ela a ser feita, como essa:
Consegue notar que esse commit consegue passar mais informações importantes, poupando tempo de investigação?
Para entender sobre como escrever boas mensagens de commit, leia o guia de mensagens de commit e convenção de commit.
Bônus:
- Use git-cz para te ajudar a escrever mensagens de commit usando a convenção.
- Valide se a mensagem está respeitando o padrão no
pre-commit, conciliando, por exemplo, commitlint e husky.
Como cada pessoa possui o seu estilo de codificar, é esperado de que o projeto de automação, por ter mais de 1 pessoa, possua vários estilos diferentes.
O código abaixo, escrito por 2 pessoas, possui as seguintes diferenças:
- Espaçamento no início do código.
- Uso de ponto-e-vírgula.
- Uso de aspas duplas e aspas simples.
Para solucionar esse problema use um formatador de código opinativo, como o prettier, para garantir que todo o código esteja consistente e com um estilo único, facilitando sua leitura.
Bônus: Execute o prettier no
pre-commitcom husky, para garantir que todo código enviado esteja padronizado.
É importante que o seu projeto possua uma boa documentação, pois é ela que vai informar para as outras pessoas sobre qual o papel do projeto, como configurar, executar, contribuir e outras informações importantes.
Código sem documentação é difícil de ser operado por pessoas alheias ao projeto, que terão que perder tempo analisando o código para entenderem um pouco sobre o mesmo.
Por isso, foque em escrever um README.md para o seu projeto. A extensão .md é de markdown, uma linguagem simples de marcação que apoia a escrever com boa produtividade textos organizados.
README.md é tão importante que todo projeto open source procura ter ele bem detalhado e atualizado.
Exemplo de markdown extraído do projeto open source protractor-helper
Para saber mais, veja esse ótimo tutorial de markdown.
Essa dica serve apenas para javascript
Quando estiver instalando as dependências necessárias para o seu projeto, é importante identificar quais são necessárias apenas para desenvolvimento e quais são para a execução dos testes.
Essa separação é importante para quando outra pessoa ou o ambiente de CI for rodar a sua automação, ele baixe apenas as dependências necessárias. Afinal, para rodar os testes não é importante baixar o pacote de validação de commit. É preciso ter em mente também de que algumas dependências possuem dezenas de dependências, fazendo com que, de forma fácil, seja baixado mais de 100 pacotes de forma desnecessária.
Exemplo de separação
Nessa situação, quando for fazer a instalação apenas para executar a automação, utilize:
npm install --production
Para saber mais, leia a documentação do package.json e do npm-install.
Se chegou até aqui, não deixa de fornecer feedback e curtir o post 😃
Gostou do assunto e quer saber mais? Leia Por favor, “don't code like a tester” um ótimo post do Leonardo Galani e de onde tirei a frase 'Código de teste é software e deve ser tratado como tal'.