Falar de automação de testes talvez seria uma das últimas coisas que eu faria, e ca estou eu e o intuito é passar a visão de alguém que lutou e lutou e que no fim resolveu “dar uma chance” para a tão sonhada e para alguns a bala de prata, chamada automação. E a primeira dica que talvez eu possa dar é que para que haja o primeiro passo, o cidadão tem que simplesmente “querer” e na época eu quis e tive a ajuda e talvez um “norte” do meu grande amigo Eduardo Freitas, que naquele momento estava realizando um trabalho de automação no SAP e foi me passando um pouco sobre automação no selenium IDE. Já havia trabalhado com IDE algumas vezes.
Bom o intuito aqui é mostrar que pode ser interessante e muito divertido “desenvolver testes”, vou chamar assim para que não haja fantasmas quando se fala em “automação”. Eu acredito que palavras geram bloqueios e que títulos novos geram motivação e curiosidades. Vou enumerar para que fique bem fácil, assim como foi pra mim =).
1. O início
Acredito ser a principal parte, que nada mais é que a curiosidade em dar uma chance. Se der uma chance por si só, sem que haja pressão externa, ou opiniões opressoras ou opiniões que possam criar novos bloqueios e aquelas opiniões escrotas que dizem que quem não automatiza está fora do mercado o resultado chega a ser surpreendente. Então, acordar e pensar assim: “Hoje vou dar uma chance em desenvolver meus testes” já servirá de motivação para continuar o trabalho. Se ocorrer de não gostar, tente dar mais umas três chances e se depois disso nada rolar, não tem problema, seu lugar no mercado ainda é bem visto e cada um tem seu valor ;).
2. Por onde começar
No meu caso, pedi ajuda para aprender selenium IDE e começar pelo IDE de certa forma abre mentes, pois a interface é amigável, vc não terá muitas linhas de comando e se colocar na cabeça que é um simples “passo a passo” de um cenário, o trabalho flui melhor. Usar e abusar do record and play também é muito válido, pois dessa forma as pessoas vão se familiarizando com cada comando gerado. Naturalmente depois você desapega dessa prática e passa a usar comando a comando.
Uma coisa que é importante colocarmos na nossa cabeça é que toda tela possui elementos e que elementos passam a ser o coração da automação, pois são esses mesmos elementos que eu vou clicar, escrever, selecionar, etc. Então vamos a pequenas dicas:
a. Comandos como Click, ClickandWait, Type, WaitforElementPresent, WaitforTextPresent, AssertText, Selectandwait são alguns comandos que acabam fazendo boa parte do que precisamos e todos eles precisam informar os elementos no campo Target do selenium.
b. Utilizar o firebug é essencial para identificar os elementos.
c. Não se assuste com o HTML, sempre tem o “inspecionar elemento” que vai direto para o elemento em questão.
d. Todo elemento pode ser identificado por um “id” ou buscamos por “css” ou “xpath”. O id ta escancarado no html rs, mas se não tiver id, clique com o botão direito na seleção no firebug e lá terá as opções de copiar o css ou xpath. É simples, copie e no campo target, coloque “id=xxxx”, “css=xxxx” ou “xpath=xxxx”. Nesse momento não se preocupem com o tamanho das strings geradas para css e xpath, depois vamos melhorar nossa busca de elementos utilizando outras técnicas, mas para o início basta. Para certificar que o elemento é aquele mesmo, basta clicar no botão find do selenium e o elemento ficará em amarelo e vai piscar.
e. No início, não se preocupem em utilizar e abusar dos comandos wait (até porque da um certo folego no passo a passo e não vai passando por cima de um passo ou outro) e lembre-se, você está no início, boas práticas agora não competem a você, vc precisa do negócio funcionando e vai funcionar.
f. A cada sucesso, execute e veja rodando e aumente a auto-estima, salve e parta para uma nova conquista.
Viram como até agora não precisamos de programar nada, é buscar elemento e passar pro próximo passo e depois rodar e ver a mágica acontecer.
3. O desapego
Agora vem a parte do desapego, pois uma hora que tu já começa a ver muitas coisas funcionando, vc acaba percebendo que o IDE já não é tão atrativo. É nessa que vamos desejar almejar voos mais altos e atuar no webdriver.
4. A escolha certa para o seu contexto.
Escolher uma linguagem de programação para atuar com os testes não é uma tarefa simples, no meu caso, optei por ruby + test::unit (biblioteca nativa do ruby para testes), ela é amigável, simples de usar e muitos devs conhecem, e no meu caso, todos da equipe de dev utilizam no dia a dia e com isso tirar dúvidas é muito mais simples.
5. E agora???
Após escolher a linguagem a se trabalhar, não pensem que iremos começar do zero tudo de novo, pois podemos exportar o que fizemos na linguagem que escolhemos e a partir daí ter uma nova curva de aprendizado, pois veremos os comandos que colocamos no IDE de forma “traduzida” para a linguagem. As dicas para ruby são bem simples:
**a. Estruturas básicas:
** a.1. Ter na cabeça que temos classes e métodos. Quando exportamos, o IDE traz essa estrutura pra você.
b. No início, faça um “linguição” dentro de um método só, Lembre-se que cada linha do método significa um passo a mais no seu teste. Cada método inicia com “def” e finaliza com “end”. Para o método ser executado, lembre-se que deve iniciar “test_”, pois o test::unit vai interpretar e vai iniciar o passo a passo. Então, dentro do export, procure por esse método e coloque-o antes do último end (classe). O restante dos métodos, deixem do jeito em que estão (por hora é isso). Foque apenas no método que contenha o teste.
c. A essência do test::unit, assim como no IDE está na busca de elementos na tela e depois posso clicar, selecionar, escrever, etc. Outro detalhe bem legal no test::unit, assim como em outras linguagens, é que o trabalho começa a ficar bem repetitivo, ou seja, é tranquilo andar com as próprias pernas. Como a busca de elementos é o X da questão, os comandos se repetem, nesse caso, "@driver.find_element(:id,css ou xpath, “id, caminho do css ou xpath” ".
Vou colocar abaixo um exemplo de um método em ruby de um teste básico de login:
Início dos testes
Método de aprendizado. Testando Login
def test_login
@driver.get "http://enderecoweb.com.br"
@driver.find_element(:id, “id do elemento Logar”).click
@driver.find_element(:css, “html.js body.welcome-controller div#top-bar.slogan div.container div.action-links div.dropdown a#user-name-link.bold” do elemento informe o login).send_keys "teste@teste.com.br"
@driver.find_element(:xpath, “/html/body/div[2]/div/div/div/a” do elemento senha).send_keys “password0001”
@driver.find_element(:id, “id do elemento entrar”).click
# O comando assert vai certificar que no campo X o nome teste deve aparecer. Qualquer coisa diferente disso, ele vai falhar o teste. Fazendo um paralelo, funciona como o waitforTextPresent. #
assert(@driver.find_element(:id, “id do elemento”).text == “teste”)
end
Fim do método de Login
Fim dos testes
6. Executando o script.
Para deixar claro, como escolhemos test::unit para criação e selenium como driver, temos que ter as seguintes gemas instaladas no ruby:
selenium-webdriver
test-unit
Bom, dado que o ruby esteja instalado em sua máquina, executar com o comando “ruby + nome_do_arquivo”, então ele irá abrir o navegador, rodará os testes e finalizará. O Log vai aparecer da seguinte forma:
1 tests, 1 assertions, 0 failures, 0 errors, 0 pendings, 0 omissions, 0 notifications
100% passed
Bom galera, os mitos a cada dia vão caindo, “desenvolver testes” pode ser mais divertido do que qualquer outra coisa. É prazeroso ver um fluxo que se fazia manual ficar automático e rápido, e cada sucesso, salve, e crie outro método e outro e outro.
Como falei, no início, esqueça as boas práticas e foque no aprendizado, escute os desenvolvedores que irão te ajudar, não queira deixar o negócio todo bonito porque ta no livro do Martin Fowler logo de cara, quando o nível de maturidade for chegando a um patamar melhor, iremos ver que a cada dia que passa iremos melhorando nossos testes, melhorando a forma de escrita, aprendendo mais. Pergunte sempre ao google sobre um problema, que ele vai te responder e vc vai conseguir aplicar.
Hoje estou entrando em um contexto para desenvolver em BDD com cucumber + capybara. É um pouco diferente, mas é bem legal, porém o início eu acredito que pelo test::unit seja o melhor dos mundos, a visão vai se abrindo e depois que o bloqueio foi tirado, não importa por onde você vai “desenvolver”, você irá conseguir e na minha opinião, é bemmmm mais fácil. Em paralelo, estudando uma ferramenta muito boa para automação em ambiente mobile (utilizando o próprio device) e estou entrando em um seleto grupo que automatiza para mobile =).
Estou aberto para tirar dúvidas, mandar exemplos, etc.
Se hoje sou um QA mais completo, não sei, mas minha opinião de que há lugar para todo mundo não muda. Funcional ou técnico, extraia o melhor de ti e não dê ouvidos teorias da conspiração, seja o melhor e é isso ai.
Até o próximo.