Concordion: Introdução

Em um ciclo de desenvolvimento de software, a etapa de testes sempre estará presente, ocorrendo independentemente do modelo de processo de desenvolvimento escolhido (sequencial, incremental, evolutivo), da metodologia (RUP, Lean, Crystal, Scrum, XP), da abordagem, técnica ou filosofia aplicada (TDD – Test Driven Development, DDD – Domain Driven Design, BDD – Behavior Driven Development ou ATDD – Acceptance Test Driven Development).

A importância e a priorização dos testes vêm aumentando desde o notório avanço do manifesto ágil. Dado esse fato, a criação de frameworks para auxiliar as atividades de teste é, no mínimo, uma evolução tecnológica natural.

Ao fazer essa constatação e observar as atividades de teste, nota-se a consolidação do JUnit como um framework para a realização de testes unitários.

No entanto, quando se trata de testes de aceitação, não existe um framework no mercado que tenha o mesmo reconhecimento. Para preencher esta lacuna, surgiu o Concordion, cujo foco é a legibilidade da especificação do teste de aceitação e a fácil execução.

Com base nisso, neste artigo será apresentado o conceito do que é teste de aceitação e, em seguida, será introduzido o Concordion, a sua estrutura, seu funcionamento, os comandos básicos para criar uma especificação, a sua utilização, e configuração em conjunto com o Maven e o JUnit.

O que vem a ser um teste de aceitação?

Na definição do notável Roger Pressman, um doutrinador da engenharia de software, o teste de aceitação se inicia no fim do teste de integração, quando os componentes individuais do software já foram exercitados (testados e corrigidos), o software está completamente montado como um pacote e os erros de interface já foram descobertos e corrigidos.

Esse tipo de teste utiliza como base as ações e saídas visíveis ao usuário, e o teste se torna bem sucedido quando o software funciona do modo esperado pelo cliente.

Segundo Ian Sommerville, outro doutrinador da engenharia de software, o teste de aceitação é definido como um processo de teste do usuário. Neste processo, cabe ao usuário atestar a qualidade do software e decidir se o que foi testado é bom o suficiente para ser implantado e utilizado em seu ambiente operacional, em produção.

Além disso, o glossário do ISTQB (International Software Testing Qualifications Board), Conselho Internacional de Qualificações para Testes de Software, define que o teste de aceitação é um teste formal relacionado às necessidades dos usuários, requisitos e processos de negócios. É realizado para estabelecer se um sistema satisfaz ou não os critérios de aceitação e para possibilitar aos usuários, aos clientes e às outras entidades autorizadas, decidir aceitar ou não determinado sistema.

Acerca das definições anteriores, cabe complementar que os termos “sistema” e “software” são tratados como sinônimos. Além do mais, em alguns locais ou publicações, o teste de aceitação também pode ser referenciado como “teste de validação”.

Ainda sobre as definições anteriores, é evidente a importância, a participação e o comprometimento do usuário ou cliente, que possui tanto o poder de aprovação quanto o conhecimento de o que deve ser testado.

O estereótipo do teste de aceitação

Na orientação de Dan North, idealizador da abordagem BDD, é possível estereotipar um teste de aceitação utilizando uma estrutura simples, como um molde, para criá-los. Este estereótipo é definido pela sentença “Dado-Quando-Então”, tradução do original “Given-When-Then”; no qual o conectivo “Dado” é relativo a um contexto para o teste, ou a um cenário; o conectivo “Quando” se refere a uma ação, a um acontecimento, ou a um gatilho, em conjunto com as entradas para o início do teste; e o conectivo “Então” diz respeito à consequência, à reação, ou ao comportamento esperado após a execução do teste, isto é, são as suas saídas.

Para demonstrar esse estereótipo, segue um exemplo, no formato tabular, para facilitar a compreensão:

· Dado um cálculo simples;

· Quando for solicitado a soma de 2 + 3;

· Então o resultado exibido será 5.

Além disso, também é possível transcrever o exemplo anterior no formato de um parágrafo, a fim de aproximá-lo da linguagem falada, como segue: “Dado um cálculo simples; quando for solicitada [D1]a soma de 2 + 3, então o resultado será 5”.

Uma vez dominada a ideia do estereótipo do teste de aceitação, é possível suprimir os conectivos e, também, omitir a oração que possui o conectivo “Dado”, visando tornar o teste de aceitação mais objetivo e coeso, como no seguinte exemplo: “No cálculo da soma 2 + 3, o resultado deve ser 5”.

Percebe-se que, independente de suprimir os conectivos ou de resumir a sentença, o estereótipo do teste de aceitação demonstra a relação de “causa e consequência”.

Esta relação deve ser respeitada com o objetivo de tornar o teste de aceitação o mais legível possível, independente de quem possua a responsabilidade de concebê-los, que poderá ser delegada para o usuário ou cliente, ou para a equipe de TI, ou ainda compartilhada entre ambos.

Em virtude da facilidade de criação e da importância do teste de aceitação, o próximo passo seria a sua automatização. É justamente neste ponto que entra o Concordion.

Concordion, primeiros passos

O Concordion é um framework para a escrita e automatização de teste de aceitação, e suas principais características são: o uso do HTML para a escrita e o uso do framework JUnit como motor de execução."