Artigos Java Web services: testes funcionais e automatizados com Cucumber
Por que eu devo ler este artigo: A utilização de web services baseados em XML é bastante comum, e seu uso continua aumentando, especialmente por conta dos produtos e soluções SOA, que adotaram o XML como padrão. Executar testes nesses cenários é uma tarefa bastante complexa, ainda mais quando os testes se concentram na validação de dados de payloads XML. Em muitos desses cenários os testes de dados em payloads exigem o mapeamento do XML para POJOs a fim de recuperar os dados a serem validados, tornando o desenvolvimento mais lento e complexo. Neste artigo será mostrado como a utilização do Cucumber pode melhorar e incrementar as possibilidades de testes de payloads XML em ambientes com uso extensivo de web services. A ideia central é criar uma infraestrutura para testes de forma a unir as facilidades que o Cucumber possibilita, como automatização de testes e criação de cenários, com as tecnologias relacionadas à linguagem XML, como XPath, de forma que as validações de payloads sejam feitas diretamente nos payloads XML, ao invés de implementar o mapeamento entre o payload e o objeto para a validação dos dados. Dessa forma, o desenvolvimento de testes se torna muito mais simples e rápido.

Há muito tempo a utilização de web services vem aumentando gradativamente. Nesse cenário, atualmente, quase tudo é feito com o auxílio de web services. A preferência pela utilização de serviços deve-se, em grande parte, ao baixo acoplamento, manutenibilidade e, o mais importante, ao reuso e à rapidez no desenvolvimento que a adoção de web services propicia às organizações.

Em relação à análise e desenvolvimento de serviços, as organizações já atingiram um nível de maturidade bastante elevado. Além disso, a abordagem para esses temas na literatura técnica, como análise e projeto de serviços e criação de inventário de serviços, é bastante difundida. Um desafio, no entanto, surge em meio a essas já maduras técnicas de desenvolvimento orientadas a serviços: os testes.

Testar serviços pode ser uma tarefa complexa devido às particularidades que envolvem a criação de web services. Um serviço pode gerar dados em diferentes formatos, como XML e JSON, pode ter um contrato especificando a estrutura desses dados e ainda há a preocupação com o conteúdo gerado. Outro atenuante das dificuldades de se testar web services é a gama de tecnologias que podem ser — e na maioria das vezes são — utilizadas para sua implementação. Enfim, são muitas características técnicas e de negócio a serem levadas em consideração para realizar os testes de serviços.

Testes manuais em web services são bastante custosos devido a tantas variáveis nesses cenários, tais como o comportamento de um ESB, que deve ser simulado para garantir um teste completo de uma mensagem até ela atingir seu destino final. Nesses casos, a automação é o caminho a seguir, pois elimina a recorrência de erros comuns em ambientes de alta complexidade. Ainda assim, dependendo do uso que se faz dos web services e de como está projetada a arquitetura sob a qual os mesmos serão utilizados, esses testes podem se tornar muito complexos. Ademais, testar os clientes desses serviços também não foge à regra da complexidade, e podem, inclusive, ter um nível de dificuldade ainda maior, pois deve-se se preocupar com o mapeamento de todos os cenários funcionais possíveis para um serviço exposto.

Em sistemas mais complexos, onde todo o processamento das informações depende de web services, como orquestradores de serviços, os testes dos clientes se mostram mais difíceis de acordo com as tecnologias utilizadas. Imagine um mecanismo em um orquestrador de serviço que lê um payload em XML e o transforma com um XSL para enviar o payload de saída para algum serviço. A Figura 1 ilustra a arquitetura desse sistema e a utilização de web services em seu processamento.

Nessa arquitetura, web services são imprescindíveis para o seu funcionamento pois, como são utilizados de diversas formas por meio de diferentes tecnologias (linguagens de programação), suas características de independência de plataforma e linguagem fazem muito mais sentido para implementação. Além disso, conceitualmente falando, do ponto de vista da arquitetura SOA, um serviço é uma função computacional disponibilizada por outro sistema de forma independente dos clientes. Na arquitetura apresentada na Figura 1, note como são utilizadas tecnologias de parsers para a geração de payloads em XML, diferentes protocolos de comunicação e vários tipos de modelos de dados. Tudo isso torna a arquitetura bastante complexa.

Exemplo de como um orquestrador de serviços funciona
Figura 1. Exemplo de como um orquestrador de serviços funciona.

Este artigo aborda a aplicação de BDD e especificações funcionais ao processamento de dados gerados por meio de transformações (usualmente XSL) para serem consumidos por web services. Considerando essa situação, um dos principais problemas está relacionado à integridade dos dados. Como testar a integridade? Além disso, qual seria a melhor abordagem para escrever os testes? Deve-se fazer o parser dos XMLs de saída e compará-los com objetos ou criar arquivos XML de saída esperados? É muito difícil eliminar toda a complexidade presente em um cenário como esse. Contudo, podemos amenizar as dificuldades por meio da utilização de frameworks de testes automatizados.

Os próximos tópicos deste artigo abordarão como o Cucumber pode auxiliar na implementação da abordagem BDD, além de prover um ambiente pronto para automatização dos testes.

Cucumber

O Cucumber é uma ferramenta de testes construída sob o conceito de BDD que possui di ...

Quer ler esse conteúdo completo? Tenha acesso completo