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 ...