Headless BrowserUma das coisas que mais gosto quando programo com Rails é que os testes integrados com a interface gráfica utilizam um headless browser. Um headless browser é, como o nome diz, um “navegador sem cabeça”, ou seja, sem janela, sem interface gráfica. Seu único propósito é testar, e por não ter o overhead natural que uma janela e aquele monte de funcionalidades que um browser completo tem, ele é muito, muito rápido. Isso permite rodar testes integrados com interface gráfica muito rápido quando usamos essa técnica.

Um tempo atrás eu havia procurado um headless browser pra .NET, sem sucesso. A tecnologia importa, porque você precisa programar o navegador no seu código. Por esse motivo eu não poderia usar o de Ruby, sem ter que fazer um certo voodoo com IronRuby (que tem problemas com o Nokogiri e Capybara), ou implementar meus testes em Ruby, o que, apesar de ser legal, ia me trazer limitações no contato com todo o resto do meu código, escrito em C#.

Neste sábado passado eu ministrei um curso in company de BDD, e um dos módulos toca no assunto automação da interface gráfica nos testes. Fiz os exemplos usando Selenium, e citei a ideia do headless browser. Os alunos questionaram porque não usar, expliquei que não tinha, mas pra confirmar, fui procurar. E achei. O projeto ainda está no começo, mas o SimpleBrowser funcionou razoavelmente bem nos testes que fiz. Ele é todo implementado em C#, ainda não suporta Javascript, e está em desenvolvimento ativo. Esse é um estágio que a comunidade de Ruby já passou. Outro problema é que você não pode, de maneira fácil, trocar entre Selenium e SimpleBrowser, já que as APIs são diferentes (problema também já resolvido no Ruby, com o uso de APIs comuns, como o Capybara).

Outro problema a ser resolvido é a integração do driver do browser com a aplicação em si, e como rodá-la. Ainda temos que fazer todo o wiring de iniciar a aplicação na mão. Mas imagino que isso tudo ainda será resolvido num futuro próximo. O código que fiz como exemplo está no meu github, e, se você for usar, vai precisar rodar a aplicação antes, já que não me preocupei com esse código de bootstrap, uma vez que esse não era o foco.

Apenas pra deixar claro como vale a pena, pra rodar 2 testes de interface gráfica com Selenium, levo cerca de 12 segundos, já que ele precisa abrir o Firefox, e isso leva bastante tempo. Com o SimpleBrowser, o mesmo teste leva cerca de 2 segundos. Os testes em si levam cerca de 500 milisegundos com Selenium/Firefox e 50 milisegundos com o SimpleBrowser, sendo que a diferença é o tempo de abertura e fechamento do Firefox e do SimpleBrowser. Dessa forma, temos cerca de 6x de ganho de desempenho em testes rápidos, onde o navegador é aberto e fechado rapidamente, e 10x em testes mais longos, onde esse tempo importa menos. São números impressionantes.

A API do SimpleBrowser também é bem melhor que a do Selenium. Aqui você vê a implementação dos steps com Selenium, e aqui com SimpleBrowser. Pra exemplificar:

Selenium:

[When(@"eu acrescento o produto (.*)")]
public void QuandoEuAcrescentoOProduto(string produto)
{
    FF.FindElementByName("produto").SendKeys(produto);
    FF.FindElementById("acrescentar").Click();
}

SimpleBrower:

[When(@"eu acrescento o produto (.*)")]
public void QuandoEuAcrescentoOProduto(string produto)
{
    Browser.Find(ElementType.TextField, "name", "produto").Value = produto;
    Browser.Find(ElementType.Button, "id", "acrescentar").Click();
}

Pra falar a verdade, não gosto nem um pouco deste método “SendKeys”. Nessa briga, o Watin ganha de longe.

Preciso ainda fazer testes mais extensos com o SimpleBrowser, mas sem dúvida ele vai entrar nos meus próximos testes que não envolverem Javascript.

tags

bddJavascriptTestes Automatizados

Giovanni Bassi

Arquiteto e desenvolvedor, agilista, escalador, provocador. É fundador e CSA da Lambda3. Programa porque gosta. Acredita que pessoas autogerenciadas funcionam melhor e por acreditar que heterarquia é mais eficiente que hierarquia. Foi reconhecido Microsoft MVP há mais de dez anos, dos mais de vinte que atua no mercado. Já palestrou sobre .NET, Rust, microsserviços, JavaScript, TypeScript, Ruby, Node.js, Frontend e Backend, Agile, etc, no Brasil, e no exterior. Liderou grupos de usuários em assuntos como arquitetura de software, Docker, e .NET.