Testes automatizados funcionais - passo a passo

INTRODUÇÃO

Este documento descreve uma sequência de passos padrão para a automatização de casos de teste do Pje utilizando o framework desenvolvido pelo CNJ. O framework foi desenvolvido com objetivo de separar a lógica de execução dos casos de teste dos dados necessários para a execução. Para isso, foram criados três componentes básicos para a execução:

• um arquivo xml com os dados necessários para a execução;
• uma classe de dados que encapsula os elementos do arquivo xml em uma estrutura de fácil manipulação pelo desenvolvedor;
• uma classe (ou mais) responsável pela execução do caso de teste com base nos dados encapsulados pela classe de dados.

A estrutura proposta é ilustrada na figura seguinte.

É importante observar que, independentemente da forma de implementação da classe de execução, obrigatoriamente devem ser criados os três artefatos descritos na figura, visto que o framework está “esperando” pela existência dos três para a execução dos cenários.

PASSO A PASSO

Este capítulo descreve uma sequência de passos sugerida para o desenvolvimento de casos de teste com base no framework criado. Trata-se apenas de uma sugestão que, com base na experiência de uso do framework, tem se mostrado eficiente para o desenvolvimento dos casos de teste do Pje.

Determinação da estrutura de dados

O primeiro passo consiste em determinar a estrutura de dados necessária para a execução do caso de teste que se pretende executar. Numa visão similar a de um caso de uso, esta estrutura deve prever os dados necessárias para a execução de todos os cenários possíveis, tanto cenário principal, quanto cenários alternativos e de exceção.

Para isso deve-se executar manualmente o caso de teste que se pretende automatizar, de acordo com o desenho do caso de teste. Esta execução manual deve produzir uma lista de dados necessários para a execução automatizada.

A figura abaixo exibe a tela de cadastro de etnias do PJe, que é usada neste documento como exemplo para criação de um caso de teste.

Para a execução deste caso de teste são necessárias duas informações: a descrição da etnia e a situação. Com estas informações é possível partir para o segundo passo, que é a construção do arquivo XML com os dados para execução.

Criação do arquivo xml

O passo seguinte consiste em criar o arquivo XML para o armazenamento dos dados de execução. Este arquivo deve estar presente dentro do diretório /xml do projeto dos testes. A Figura seguinte ilustra um arquivo XML para o cadastro de Etnias no Pje.

O arquivo XML possui um nó raiz chamado TestCase, com alguns atributos que são apresentados em seção específica. Importante observar que o nome do nó raiz obrigatoriamente deve ser TestCase, pois este nome é esperado pelo framework. Para evitar problemas com relação à estrutura do arquivo criado, recomenda-se, quando for criado um arquivo XML para um caso de teste, que este seja duplicado a partir de um arquivo já existente, para aproveitar a estrutura já criada e testada.

O arquivo XML em questão descreve uma estrutura de um caso de teste que possui dois cenários do tipo CadastroEtnia. Importante observar que o nome do arquivo XML é CadastroEtnia.xml. Este nome deve corresponder semanticamente ao propósito do caso de teste, qual seja, o cadastro de etnias. Importante observar que os nós que descrevem cenários devem ter o mesmo nome do arquivo XML, sem a extensão .xml. Mais informações sobre a nomeclatura dos aquivos podem ser obtidas neste documento.

Os dois cenários são declarados entre as linhas 5 e 13 (cenário 1) e entre as linhas 15 e 23 (cenário 2). O nó que descreve os cenários possui alguns atributos de interesse cuja documentação está disponível pode ser acessada por aqui.

Algumas observações sobre a relação entre o arquivo xml e a página cuja execução será automatizada:

• as linhas 8 e 9 do arquivo XML descrevem os valores necessários para o preenchimento dos campos da página. Os nomes destes nós são livres, contudo, recomenda-se que correspondam semanticamente aos nomes dos campos no Pje.
• entre as linhas 10 e 12 são declarados os resultados produzidos pelo cenário, que poderão ser utilizados na execução dos cenários seguintes. Este nó é opcional. Contudo, caso exista, obrigatoriamente deve se chamar resultados. Dentro deste nó são declarados nós com o nome resultado (no singular). O valor declarado dentro de um nó resultado (ver exemplo na linha 11) deve corresponder exatamente ao nome de um atributo presente na classe de dados. Este atributo não precisa necessariamente estar presente no xml (apesar de frequentemente estar presente), mas, caso seja declarado em resultado, deve estar presente na classe de dados. Ainda, para ser utilizado pelos cenários subsequentes, os arquivos de dados destes cenários também devem declarar o atributo com o mesmo nome na classe de dados. Mais informações sobre o recurso de resultados de cenários podem ser acessadas aqui.

Criação da classe de dados

Após criado o arquivo XML deve-se criar a classe de dados para encapsulamento dos atributos declarados. Esta classe deve estar em um pacote definido de acordo com o padrão de estrutura da instituição. Entretanto, definido o pacote, este deve ser declarado no arquivo XML, no cabeçalho do caso de teste, conforme ilustrado na linha 3 do código fonte exibido na figura acima.

O nome do arquivo da classe de dados deve ser exatamente o nome do arquivo XML, precedido da palavra Dados. Com isso, para o arquivo CadastroEtnia.xml, o arquivo da classe de dados deverá ter o nome DadosCadastroEtnia. A seguinte exibe o código fonte da classe de dados do caso de teste de cadastro de etnia.

Algumas características da classe de dados são importantes para a execução correta do caso de teste:

• os atributos declarados nas linhas 8 e 9 deve ter exatamente os mesmos nomes dos nós declarados nas linhas 8 e 9 do arquivo XML ilustrado pela Figura acima.
• todos os atributos declarados devem possuir os métodos de acesso (get e set), pois estes serão utilizados pelo framework para a alimentação dos valores dos atributos.
• classes de dados devem sempre herdar de uma das classes de dados presentes no framework. A classe em questão herdou da classe DadosCadastro. Contudo, outras classes de dados podem herdar de qualquer classe abstrata presente na hierarquia da superclasse Dados, presente no pacote do framework.
• os atributos de valores atômicos declarados no arquivo XML, como é o caso daqueles dois apresentados nas linhas 8 e 9 do arquivo ilustrado pela Figura acima, são alimentados automaticamente pelo framework na classe de dados, através de reflexão. Ou seja, estes valores não precisam ser alimentados manualmente pelo desenvolvedor.
• valores que não sejam atômicos (que sejam estruturados em nós e subnós) devem ser carregados programaticamente pelo desenvolvedor, dentro do método carregarDados. Na classe ilustrada pela figura acima não houve necessidade desta implementação, visto que todos os atributos são atômicos. O método carregarDados é invocado automaticamente pelo framework (desde de que a classe herde de alguma classe da hierarquia da superclasse Dados) e receberá como parâmetro, no caso exemplificado, um nó com o nome CadastroEtnia, como aquele descrito entre as linhas 5 e 13 da do arquivo XML acima. Cabe então ao desenvolvedor alimentar manualmente eventuais atributos compostos. Recomenda-se o estudo de alguns casos de teste que tenham atributos compostos como, por exemplo, CadastroProcesso.

Criação da classe de execução

O último passo sugerido é a criação da classe que irá efetivamente executar o caso de teste. Classes de execução são o único ponto da arquitetura em que há código Selenium. Esta classe deve ser criada no mesmo pacote em que foi criada a classe de dados, e deve ter o mesmo nome desta, sem o prefixo Dados. Para o cenário de cadastro de etnias, os arquivos terão os seguintes nomes:

• arquivo XML: CadastroEtnia.xml
• classe de dados: DadosCadastroEtnia
• classe de execução: CadastroEtnia

Se não for respeitado este padrão de nomenclatura o framework não consegue instanciar dinamicamente as classes, e é lançada uma exceção do tipo ClassNofFoundException. A figura seguinte exibe o código da classe de execução do cadastro de etnia.

Algumas considerações sobre a implementação da classe são importantes. Todas as classes de execução devem herdar de alguma superclasse da hierarquia de CenarioPJe. Esta herança obrigará a implementação do método executarTeste(), que é invocado internamente pelo framework. Além da classe CenarioPJe é possível que a herança seja feita a partir de classe CenarioPJeDocorator e suas subclasses. Esta herança obrigará a implementação dos métodos preExecucaoTeste() e posExecucaoTeste(), que também são invocadas internamente pelo framework. A ordem de invocação destes três métodos, bem como de outros presentes no framework é apresentada no diagrama de sequência ilustrado pela figura abaixo.

O entendimento desta ordem de execução é importante para que a classe de execução seja programada corretamente. Por exemplo, o método executarTeste() deve conter apenas código referente a ações de preenchimento de campos. Por sua vez, o método preExecucaoTeste() deve conter código relativo a ações executadas antes do preenchimento dos campos como, por exemplo, código para aguardar a presença de algum componente da página que permita o início do preenchimento dos campos. Por fim, no método posExecucaoTeste() devem ser programadas ações a serem realizadas após o preenchimento dos campos como, por exemplo, um clique no botão de gravar o conteúdo da página.

Destaca-se no código apresentado na figura acima a instrução presente na linha 11. Este exemplo mostra como utilizar as informações presentes na classe de dados. Os valores presentes na classe de dados são povoados internamente pelo framework, conforme apresentado nesta seção.

Demais configurações do arquivo XML

Outras configurações estão disponíveis no arquivo XML, cuja documentação pode ser encontrada em seção específica, tais como a outros cenários, de cenários, esperados e resultados encontrados e, por fim, cenários decorados.