Testes unitários não são para serviços de negócios

Há alguns anos tenho trabalhado com orientação a serviço e mais recentemente assumi uma diretoria de qualidade na empresa que trabalho.

Com esse novo posto tive a oportunidade de olhar o software que desenvolvíamos com outros olhos, o da qualidade.

Quando pensamos em qualidade, a primeira atividade que nos vem à mente é TESTES, embora tenhamos a percepção de que há muito mais por trás da qualidade do produto do que apenas uma atividade.

Entretanto, pelo menos neste post, vou me concentrar na discussão dos testes de sistemas, normalmente de caixa-preta, em detrimento dos testes unitários (caixa-branca) para os serviços de negócio.

Não quero com isso menosprezar os outros níveis (Integrado, Aceitação, Alpah, Beta, ...) e abordagens de testes (performance, carga, e análises estáticas (Ex: PMD, Checkstyle, Structure101,..) do código-fonte, mas acredito haver necessidade de estabelecer a posição dos testes em relação a SOA antes de evoluirmos.

Para quem não conhece nada de SOA, sugiro alguns artigos e livros muito bons indicados na seção "Leitura Complementar”.

Mas, voltando ao tema central, testes unitários são para objetos e testes de sistemas são para os serviços de negócio.

Vamos expandir essa discussão. No livro de Thomas Erl “SOA: Principles of Service Design” ele compara os objetivos da orientação a objetos com os da orientação a serviços. As figuras abaixo resumem essa comparação no que é relevante para nossa discussão:



Objetivos da Orientação a objeto:

• Reuso e produtividade;
• Atendimento aos requisitos do negócio;
• Robustez;
• Flexibilidade; 
• Extensabilidade.

Objetivos da Orientação a Serviços:

• Todos os objetivos da orientação a objetos;
• ROI;
• Alinhamento de negócio e tecnologia;
• Federação;
• Interoperabilidade intrínseca;
• Agilidade organizacional;
• Opções de diversificação de fornecedores;
• Menor carga de trabalho de TI.

Erl coloca que enquanto a fronteira da orientação a objetos é o sistema, a dos serviços é a empresa.

O objetivo da orientação a serviço não é deixar uma aplicação flexível, extensível ou robusta é dar a empresa estas (e as outras) qualidades.

Por esta ótica, os testes unitários têm uma função de validar o componente de software em relação ao sistema em que ele está inserido, por isso, este tipo de teste é executado pelos desenvolvedores que são os conhecedores deste domínio.

Os serviços por outro lado, são mais parecidos com as aplicações, uma vez que expõe para toda a organização, ou mundo, uma capacidade do negócio.

Essas serviços são então colocados em uma grande "vitrine" para serem consumidos, combinados com outros serviços, reembalados e novamente expostos. 

Mas antes disso, necessitam ter todos os seus requisitos funcionais e não-funcionais validados, antes que o primeiro ávido consumidor tenha a chance de usá-lo.

O que eu normalmente vejo, conversando com os meus clientes, é a exigência dos “testes unitários”, que são normalmente projetos SoapUI (ferramenta para testes de web services - http://www.soapui.org). Esses projetos fornecem uma evidência da execução das operações do serviço, mas sem o formalismo dos testes tradicionais de caixa-preta, por exemplo.

Essa falta de formalismo se deve ao fato do desenvolvedor não ser um profissional da área de qualidade de software.

Mas do ponto de vista do consumidor, testar um serviço de negócio, inserido no contexto de uma aplicação, torna seu trabalho extremamente difícil e caro (voltaremos nesse tema em outro post). Imagine você sendo o primeiro a comprar um novo carro e no manual do proprietário uma instrução:

"Em caso de falha, abra um defeito no nosso sistema de bug track."

Acho que um "boa sorte!!!", acompanharia bem!!!

Abandonando a visão de que um serviço é uma porção de software reutilizável, com todo respeito aos objetos da OOAD, ele passa a ser entendido como uma interface para uma capacidade do negócio.

Tenho discutido, com sucesso, com meus clientes que os serviços de negócios precisam ser testados com os mesmos princípios de uma aplicação tradicional, sendo necessário criar suítes de testes (plano, cenário e casos de testes), usar ferramentas de automação, preparar massas de dados, verificar as pré e pós condições nos legados, usar de métodos estatísticos para selecionar os dados para os testes, avaliar a cobertura e por ai vai.

Seguindo este raciocínio, formulei cinco princípios para os testes de serviços de negócio:

1. Os consumidores não podem pagar pelos testes; 
2. Um serviço de negócio deve ser testado de forma agnóstica; 
3. O serviço de negócio é uma interface não-gráfica para os seus usuários; 
4. Testar um serviço de negócio deve ser barato; 
5. Desenvolvedores não são bons testando fora do seu domínio; 

Este post introduz este assunto para nossa discussão, no próximo irei discutir cada um dos princípios e associá-los a algumas teorias e práticas da área de qualidade de software.

Espero trazê-lo para essa discussão. Concorde, discorde, acrescente, corrija, valide, reclame. É assim que alimentamos o nosso conhecimento.