Se você usa ‘IF’ no seu código de teste, então precisamos conversar
Olá meu amigo tester. Vou repetir a pergunta:
Você usa ‘IF’s (ou Case/Switch no caso de algumas linguagens) regularmente no seu código de teste?
Se vc respondeu não para questão acima, eu tenho mais uma pergunta para fazer para você:
Você usa ‘Try/Catch/ begin/rescue’(ou equivalentes) regularmente no seu código de teste?
Se as 2 respostas forem Não, então eu lhe desejo um ótimo dia, pode voltar a zapear a internet, acessar o fórum agiletesters.com.br e compartilhar seu conhecimento com o mundo.
Caso sua resposta foi Sim para qualquer um dos casos (to fazendo if no meu post…huE), chega junto por que precisamos conversar.
Era uma vez um if …
Existe 2 motivos principais para abuso de condicionais em qualquer código.
1 — Você acabou de aprender uma linguagem de programação. (parabéns!)
2 — Você quer manter seu code base enxuto e quer reutilizar código.
Para ambos os casos, por favor deem uma olhada nisso aqui -> http://www.antiifcampaign.com/
Até que é possível relevar para pessoas no primeiro caso, agora no segundo caso, é preciso estudar um pouco mais para ponder entender até onde vale reutilizar código e como realmente se deve otimizar código.
Otimizar e reutilizar código é ótimo e maravilhoso mas quando falamos de código de teste, existe um PLUS para evitar certos tipos de reutilização.
A vida fica mais legal com exemplos certo? Ok.
Imagina que você tem um step que é algo assim (é python_ish_ mas dá para entender certo?):
def clica_botao_login():
if efetuar_login():
return True
else:
esqueci_senha()Você tecnicamente poderia usar o método acima para testar o processo de login (chamar um assert clica_botao_login() ), usar como step para teste de 'esqueci_senha' ou usar como step para todo teste.
Legal ter um step reutilizável certo?!
ERRADO
Não é legal ter um método que serve para um monte de coisa.
Você já deve te ouvido falar sobre ‘code readability’ e ‘clean code’ certo?
Se não, por favor de uma googlada sobre esses assuntos.
Quando falamos sobre código de teste, explícito é melhor que implícito.
Imagina que seu ambiente de teste está com cookies / sessão salva, o login não ocorre por N motivos, o método retorna False e você começa a receber vários emails de reset de senha.
Provavelmente você não irá fazer a mínima ideia onde está sendo enviado esses emails, já que você estará usando um step que clica no botão login.
Tudo isso porque você escreveu um step de teste que tem muitas responsabilidades.
A regra de ouro aqui é: Um step / método deve ter somente uma responsabilidade (https://en.wikipedia.org/wiki/Single_responsibility_principle)
Você deve achar isso uma besteira, mas até desenvolvedores experientes esquecem tudo isso quando começam a escrever código de teste (mesmo porque eles querem fazer o mais rápido possível para se livrar do fardo..rs).
O que você deveria fazer? Alguma coisa do tipo…
def efetua_login(*args):
... #return true or falsedef clica_botao_login():
assert efetua_login(args)def recupera_senha():
assert False efetua_login(args)
esqueci_senha(args)
Não é o melhor dos exemplos, mas nele você tem certeza que cada método tem sua responsabilidade, bate o olho e entende o que está acontecendo (tempo de debug reduzido drasticamente)
Gotta TRY/CATCH them all
Pode falar que eu sou o mestre das referências …! (nintendo paga noiz)
A primeira vez que eu usei Try/Catch em produção minha vida mudou. Parecia que um novo mundo de possibilidades se abria na minha frente e eu poderia fazer maravilhas com isso.
Acontece que esse cara é um sacana.
Quem está começando não entende direito qual exceção utilizar. No final das contas deixa aberto pegando TUDO (*) quanto é tipo de exceção para tratamento bonito e não faz a mínima ideia do que está acontecendo no código…
Sim… a vida não é esse mar de rosas, meu amigo.
Quantos de vocês já se depararam com um código que não dá erro, mas não funciona?! Aposto que mais que 50% era porque tinha um try/catch perdido em algum nível acima do método que deveria dar erro.
Eu sei que não sou o primeiro, único ou o último a ter feito esse tipo de cagada, então vamos a outra regrinha de ouro do livro de melhores práticas para automação de testes:
TRY/CATCH, nunca use em um código de teste a não ser que você esteja testando uma exceção.
Existe cenários de setup ou report que você pode utilizar, ou em unit test que você precisa testar se tal processo gera uma exceção x, mas entenda que esses cenários são pontuais.
Imagina colocar return True / assert True na primeira linha do seu método de teste. É a mesma coisa se vc coloca um try/catch no meio do seu teste.
Ou talvez se você usa try/catch com um punhado de ifs? É o inferno na terra! Bate 3 vezes na madeira para isolar!
Se você usa algum framework solido para realizar testes, eles provavelmente já tratam graciosamente elementos não encontrados e não explodem exceções na sua cara. Procure ler a API disponibilizada pelo framework antes de fazer essas gambiarrras no por ai ;)
