Uma 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.