Web services: testes funcionais e automatizados com Cucumber

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.

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