Automação de Testes End-to-End Utilizando o Nightwatchjs

Você já parou para pensar no quão desastroso pode ser a falta de testes? Talvez o caso mais famoso seja o míssil americano Patriot que causou a morte de 28 soldados e deixou 100 feridos durante a Primeira Guerra Mundial. Patriot atingiu um acampamento americano devido a um erro no arredondamento do cálculo de tempo, fazendo com que o sistema Patriot ignorasse os mísseis Scud de entrada.

Um teste poderia ter sido escrito para este cálculo, e com isso, poderiam ter enxergado esse erro antes de colocá-lo em campo.

O teste de software não é algo novo, mas, mesmo assim, ainda hoje, empresas preferem desenvolver sistemas sem uma metodologia com base em qualidade.

Veja a incoerência, quando se compra um carro, este passou por diversos testes; quando é fabricado um brinquedo, este também passa por testes para saber, por exemplo, se a tinta usada não é prejudicial às crianças, se partes do brinquedo não irão desmontar e causar acidentes, e assim por diante. Todos querem produtos de qualidade, então, por que isso não é aplicado ao Software?

O teste ponta-a-ponta, end-to-end em inglês, é uma metodologia utilizada para testar se o fluxo de um aplicativo está sendo executado conforme projetado do início ao fim.

Este tipo de teste envolve garantir que os componentes integrados de uma aplicação funcione como esperado. Para isso, todo o aplicativo é testado em um cenário real visando a simulação de um usuário.

Apenas o teste end-to-end é o suficiente?

Já que os casos de teste end-to-end simulam um usuário real, então, em teoria é a melhor escolha! O desenvolvedor ficará feliz porque, afinal, a responsabilidade de testar não é mais dele, o testador ficará feliz pois consegue simular um usuário real, então seus testes serão mais valiosos e, por fim, o gerente de projeto ou P.O ficará feliz pois isso vai garantir que o usuário final tenha uma experiencia melhor. Certo?

Errado! Para o sucesso de um projeto de software são necessários outros tipos de testes que possuem outros propósitos, como o teste unitário, por exemplo.

Principais diferenças entre o teste unitário e o teste end-to-end

O teste unitário é, na maioria das vezes, mais rápido do que um teste end-to-end por testar a menor unidade de código. Além disso, ele é mais consistente do que um caso de teste end-to-end, já que proporciona falhas isoladas sendo possível atuar diretamente no teste falho.

O grande problema dos testes end-to-end é a espera — você não sabe do erro até que ele ocorra na mão de um possível usuário. Testes unitários conseguem ser precisos, ou seja, você sabe o que deu errado com mais precisão, sem esperar chegar ao usuário.

Porém, mesmo com todas essas vantagens há uma coisa que o teste unitário não faz: SIMULAR UM USUÁRIO REAL!

Pensando em um equilibrio para o projeto de software, o Google realizou estudos sobre testes e chegou à seguinte sugestão sobre quais e quanto de cada teste utilizar em um projeto.

A sugestão é que se faça uma divisão de 70/20/10

• 70% de testes unitários;
• 20% de testes de integração;
• 10% de testes de ponta a ponta

Enfim, após toda essa teoria vamos ao que interessa, nossos casos de teste utilizando a suite de testes do Nightwatch.js, que é uma solução de teste fácil de usar.

O NightWatch.js é baseado em testes Node.js End-to-End (E2E) para aplicativos e sites. Ele usa a poderosa API W3C WebDriver para executar comandos e asserções em elementos DOM.

Pois bem, vamos começar do básico, claro. Vamos fazer um teste simples que executará uma pesquisa na homepage do Google e fará um assertion para verificar o texto pesquisado.

module.exports = {
‘Demo test Google’ : function (browser) {
browser
.url(‘http://www.google.com')
.waitForElementVisible(‘body’, 1000)
.setValue(‘input[type=text]’, ‘nightwatch’)
.keys(browser.Keys.ENTER, function(done) {
browser.pause(1000);
browser.assert.containsText(‘h3’, ‘Nightwatch.js | Node.js powered End-to-End testing framework’)
})
.pause(1000)
.end();
}
}

Simples, não?

Para finalizar algumas curiosidades :

• 1848 — Thomas Edison encontra um inseto em uma maquinaria da indústria e nomeia o problema como BUG.
• 1947 — Primeiro Bug é encontrado no computador Harvard Mark e este foi registrado como o primeiro erro encontrado em um computador.
• 1980 — Surgem os modelos prescritivos de desenvolvimento de sistemas e com eles a criação de ferramentas para efetuar os testes de software.