Testes de Aceitação e suas boas práticas

 @Test public void deveVerCursosDoAluno() { WebDriver driver = new FirefoxDriver(); driver.get("http://www.alura.com.br/dashboard");
List<WebElement> cursos = driver.findElements(By.cssClass("cursos"));
Assert.assertEquals(2, cursos.size()); Assert.assertTrue(cursos.get(0).getText().contains("TDD")); Assert.assertEquals(cursos.get(1).getText().contains("Java")); }

Mas, para que esse teste funcione, precisamos fazer muitas coisas antes: o usuário precisa estar logado, o usuário precisa ter somente os cursos de TDD e Java liberados.

Estar logado é um problema. Precisamos fazer isso antes de qualquer operação, afinal todas elas precisam do login antes. Ter o curso de TDD e Java liberado também é um problema, porque no teste de sistema, os dados ficam salvos no banco, então precisamos de uma maneira de limpar os dados. Veja só como ficaria nosso teste, em pseudo-código:

Veja que deixamos um monte de comentário no código, pois gastaríamos ainda mais linhas de código para fazer tudo aquilo. Conseguiu perceber como testes de aceitação podem ficar complicados? Pensar em como escrever esse tipo de teste com qualidade e facilidade de manutenção é então fundamental.

Nossa experiência acabou nos mostrando algumas boas práticas. Entre elas:

• Tenha uma API para criação de cenários. Montar cenários é a parte mais chata de todo o teste. Tenha alguma API, disponível via serviço web, por exemplo, na qual seus testes conseguem criar e manipular esses dados de maneira fácil, sem precisar navegar pela interface para criar tudo (às vezes seu cenário é muito complexo, e ir tela a tela, criando tudo é demorado).
• Tenha seu banco de dados sempre em um estado inicial. Dependência entre testes é complicado. Ter dados sujos no banco antes da execução do teste pode fazer com que seu teste falhe mesmo que a funcionalidade esteja funcionando. Para isso, antes de cada teste, resete seu banco para um estado inicial. Isso pode ser feito pela API de cenários, por exemplo.
• Encontre elementos no HTML por meio de algum identificador estável. Elementos numa página HTML costumam mudar com frequência. Sempre que você for capturar algum elemento, opte pelo que seja mais estável (ou seja, tenda a mudar menos). IDs e Names em particular costumam mudar pouco. Já classes CSS e XPath mudam com mais frequência.
• Use PageObjects. Faça uso de PageObjects em todas as páginas do seu sistema. Encapsular o funcionamento de cada página em uma classe facilita sua manutenção. Afinal, você mudará em apenas um lugar se a funcionalidade mudar.
• Conheça só os detalhes das páginas que você realmente precisa. Às vezes, para se testar uma funcionalidade, precisamos navegar por várias outras. Imagine que para testar B, você precisa passar antes por A. Se você estiver escrevendo o teste A, seja detalhista. Vá etapa por etapa. Agora, se estiver escrevendo o teste de B, passe por A o mais rápido que puder, e faça seu código depender da menor quantidade de detalhes possível. Assim, se A mudar, você precisará corrigir apenas os testes de A, e nem vai mexer nos testes de B.

Nós escrevemos sobre todos esses padrões de maneira muito mais profunda e detalhada. Você pode a versão estendida desse conjunto de boas práticas, que nós escrevemos em formato de padrão, e apresentamos no PLoP 2014, a maior conferência mundial sobre padrões na área de software. Discutimos muito sobre qualidade de código e boas práticas na escrita de testes automatizados isso na nossa formação de testes no Alura.

E você? O que faz para garantir que seus códigos de teste de sistema fiquem fáceis de serem mantidos?