Parametrização de Dados para Automação de Teste – Parte 2

Série de posts

Este post faz parte de uma série chamada Parametrização de Dados de Teste!
Clique neste link para acessar a série de posts, ou acesse pelo menu Série de Posts.

Introdução

Quando criamos um script de teste como, por exemplo, um script de cadastro, informamos os dados que serão utilizados nas caixas de texto. Sempre quando há necessidade de executar o script novamente poderemos ter os seguintes problemas:

  • O registro que utilizamos para o desenvolvimento do script pode estar inutilizável ou não mais presente
  • O registro já existe na base de dados, nos retornando em erro na utilização

Para resolver estes problemas, geralmente, alteramos os dados do script para que ele possa executar sem erros. Mas isso nos gera um outro problema que é a excessiva manutenção do script para a alteração dos dados.

Data Driven com JUnit

O que é Data Driven?

Data Driven, ou como chamamos em português Orientação à Dados, é uma maneira de parametrizarmos os dados do script de teste sem a necessidade de alteração dos dados fixos, uma vez que eles agora viram parâmetros.

No caso do JUnit, cada conjunto de dados é associado a execução do script. O conjunto de dados é uma execução. Se existirem quatro (4) conjunto de dados (que são as linhas que você verá lá no final do post) o script irá executar quatro (4) vezes sozinho.

Como usar o Data Driven com JUnit?

1. Entendimento dos dados que serão usados

A nossa aplicação utiliza três campos:

  • Nome
  • Cidade
  • Faixa de Idade

Logo estes três serão os dados de entrada e precisarão estar mapeados.

O resultado final depende da escolha da Faixa de Idade. Dependendo do valor selecionado o resultado é diferente.
Logo existe um dado de saída que chamaremos de resultado.

É extremamente importante, no início do seu aprendizado, listar quais são os dados de entrada e quais são os dados de saída que você precisará utilizar no script de teste.

2.  Criação dos atributos dos dados

Cada um dos dados de entrada e de saída viram atributos globais na sua classe de teste (são declarados bem no início da classe).
Como todos eles são textos colocaremos apenas o tipo de dados texto.

3. Criação do Construtor

Para que o script de teste possa interpretar os dados que serão usados dentro dele é necessário criar um Construtor em Java, passando como parâmetro os dados que serão utilizados e referenciando-os com os atributos dos dados criados acima.

Uma explicação mais simples é a seguinte: quando o script for executar ele saberá que ele é “data driven”, logo vai procurar dentro do script de teste como passar os dados para que ele possa usar no teste. O que ele irá procurar é o construtor 🙂

A criação do construtor para o Data Driven tem duas regras:

  • o tipo de acesso é sempre public
  • o nome do construtor é o mesmo nome da classe

Uma dica é colocar o nome dos parâmetros do construtor igual ao nome dos dados de entrada.

4. Criação do Data Driven

Para criar o Data Driven, que será utilizado na execução do script, precisamos seguir 4 passos básicos:

  1. Criação de um método estático chamado data() que deve retornar uma coleção de objetos (linha 2 do exemplo)
  2. Retornar, como array, uma lista de objetos (linha 3 do exemplo)
  3. Adicionar os dados que serão utilizados no script de teste (linha 4 a 7 do exemplo)
  4. Adicionar a anotação @Parameters que diz que, aquele método, contem os dados que serão utilizados (linha 1 do exemplo)

Perai, difícil isso né? Na primeira vez que eu aprendi também achei.
Isso é uma receita de bolo! É sempre assim. A única coisa que muda é a quantidade de dados.

Cada linha que inicia com a chave { é uma execução do teste.
A linha traz cada dado que será associado com os parâmetros do construtor. Para entender melhor visualize a imagem abaixo (um gif).

5. Associação dos dados

Agora que temos tudo, basta trocar os valores fixos dos scripts pelo atributos que criamos e o JUnit se encarregará de fazer o resto.

6. Informar o JUnit a execução via Data Driven

O último passo é adicionar uma anotação acima da classe @RunWith informando como parâmetro a classe Parameterized.class.

Código completo

Visualize o projeto no GitHub: https://github.com/eliasnogueira/parametrizacao-script-teste

One thought to “Parametrização de Dados para Automação de Teste – Parte 2”

  1. Legal saber que dá pra fazer isso no JUnit! Mas ainda prefiro fazer testes com o Spock (http://spockframework.org/spock/docs/1.1/data_driven_testing.html) por ser menos verboso, e aumentar o foco no negócio.

    class MathSpec extends Specification {
    def “maximum of two numbers”(int a, int b, int c) {
    expect:
    Math.max(a, b) == c

    where:
    a | b | c
    1 | 3 | 3
    7 | 4 | 7
    0 | 0 | 0
    }
    }

    E o GEB (http://www.gebish.org/) com Spock que une o melhor do Selenium, com o melhor do Spock:

    import geb.spock.GebSpec

    class GebHomepageSpec extends GebSpec {

    def setup() {
    browser.driver.javascriptEnabled = false
    }

    def cleanup() {
    CachingDriverFactory.clearCache()
    }

    def “can access The Book of Geb via homepage”() {
    when:
    to GebHomePage

    and:
    highlights.jQueryLikeApi.click()

    then:
    sectionTitles == [“Navigating Content”, “Form Control Shortcuts”]
    highlights.jQueryLikeApi.selected
    }
    }

    PS: Spock e Geb funcionam com projetos Java.

Deixe uma resposta

O seu endereço de e-mail não será publicado. Campos obrigatórios são marcados com *