Testes em aplicações SOA

vc tem o seguinte cenario

Sistema1 (invoca metodo via SOAP + …)----> Sistema2

Imagino os seguintes testes

1. Teste de código, isolando os sistemas, nos dois sistemas
2. Teste funcional no Sistema2 com um client de teste invocando todos os metodos e fazendo Coverage no Sistema2
3. Teste funcional no Sistema1 simulando o Sistema2 em todos os metodos e todas as respostas possiveis (incluindo mensagens de erro, etc).
4. Teste de integração full onde os sistemas efetivamente se falam.
5. Teste de carga (baseado no 4) durante a noite para ver comportamentos do sistema, memória, load da maquina, numero de file descriptors abertos, etc.

Imagine que o Teste 4 quebrou. Onde esta o problema? Provavelmente os testes 2 e 3 devem responder. Para este BUG vc adiciona um teste unitario no passo 1, pois vc não identificou este problema.

Faça muitas combinações. E meça os tempos de forma a identificar perda de performance a cada commit ou release, importante para identificar algum problema sério no futuro (mas não seja xiita, um bom teste com uma boa estatistica durante um bom tempo - tipo 5 - pode te dar esta informação mais detalhada).

Dessa forma vc tem controle do seu sistema e sabe qual a capacidade máxima, sabe como ele escala, sabe quando precisará comprar mais maquinas ou fazer algum refactoring E não é pego de calças na mão.

Importante falar sobre os testes unitarios: facá uso de mocks e de alguma framework de BDD, se possivel use linguagem natural mapeada para testes como usando FIT e/ou Cucumber (é ruby, mas se vc pesquisar um pouco vai saber tirar proveito da parada). Eu pensaria em integração continua com 1 (obrigatorio) e 2,3 se não atrasar muito (ou use alguma forma de paralelizar os testes, rode em varias maquinas ou varias threads, etc).

Aqui, fazemos os testes assim:

1ª etapa: Teste de cobertura e funcional, utilizando mocks, para checar a sanidade, mesmo.
2ª etapa: Teste com clientes dos serviços, para checar se as invocações estão funcionais.
3ª etapa: Teste de integração
4ª etapa: Validação do cliente

Acho perfeitamente válido invocar o código diretamente, desde que você tenha desenvolvido o serviço. Afinal, serviços também são código e, como tal, precisam ser testados diretamente. Se, algum dia, alguém de fora da equipe de desenvolvimento inicial precisar mexer no serviço, há meios de checar que essa “mexida” não vai quebrar o que já está feito.

[]´s

Olá, peczenyj !

Boa as dicas de teste ! Meu cenário é um pouco pior que isso apenas
Seria algo como:

Aplicação 1 – SOAP -> Aplicação 2 – SOAP --> Aplicação 2 (módulo interno) – SOAP --> Aplicação 2 (outro módulo interno)

Ou seja, três chamadas SOAP para fechar um ciclo completo no ambiente. Logo, vejo que terei que multiplicar os testes de 1 à 3 pela quantidade de WebServices que eu chamo durante um ciclo.

Sobre o CI eu estou bolando tudo antes de propor realmente a adoção por aqui. Mas de fato é uma excelente pedida usá-lo para os testes de 1 à 3 =D

[] 's

asaudate:

Aqui, fazemos os testes assim:
(…)
4ª etapa: Validação do cliente(…)

Essa validação é manual, certo ? O cliente ir lá e aloprar tudo, ou vocês fazem testes de validação do cliente sem a participação dele ? =P

hlegius:

asaudate:

Aqui, fazemos os testes assim:
(…)
4ª etapa: Validação do cliente(…)

Essa validação é manual, certo ? O cliente ir lá e aloprar tudo, ou vocês fazem testes de validação do cliente sem a participação dele ? =P

Exato, é um teste de aceitação.

[]´s

hlegius:

Olá, peczenyj !

Boa as dicas de teste ! Meu cenário é um pouco pior que isso apenas
Seria algo como:

Aplicação 1 – SOAP -> Aplicação 2 – SOAP --> Aplicação 2 (módulo interno) – SOAP --> Aplicação 2 (outro módulo interno)

Ou seja, três chamadas SOAP para fechar um ciclo completo no ambiente. Logo, vejo que terei que multiplicar os testes de 1 à 3 pela quantidade de WebServices que eu chamo durante um ciclo.

Sobre o CI eu estou bolando tudo antes de propor realmente a adoção por aqui. Mas de fato é uma excelente pedida usá-lo para os testes de 1 à 3 =D

[] 's

Quais destas aplicações foram desenvolvidas por você? Você concorda que, quando você consome serviços que não são seus, teoricamente eles estão testados? Você deveria testar somente os seus, e os de terceiros, você checa na fase de teste de integração, OK ?

[]´s

Opa, topico interessante

Nem vou acrescentar muito, pois concordo com o que foi dito aqui. Queria só lembrar que muitos serviços podem ser assíncronos, aó precisamos testar ESB-JMS e até mesmo databases.

Há diferentes tipos de testes, Arquitetura Distribuída, Codeless, UI, Load e Performance, Integração e por aí vai.

Uma ferramenta (paga) que estou usando junto aos meus clientes para fazer Quality Assurance - http://www.itko.com/products/lisatest.jsp

Fica a dica

Vamos la

vc tem 1 sistema que acessa outros 3 sistemas ou é uma cadeia de sistemas ?

se vc tem uma cadeia, ao meu ver vc teria que isolar cada sistema

A -> B -> C

eu testaria

1. real A -> fake B
2. fake B -> real C
3. fake A -> real B -> fake C

vc pode criar uma camada

3a) fake A -> real B -> real C

entenda como fakeX como um sistema similar que faz as ações de teste, nos fluxos esperados e de exceção.

asaudate:

Quais destas aplicações foram desenvolvidas por você? Você concorda que, quando você consome serviços que não são seus, teoricamente eles estão testados? Você deveria testar somente os seus, e os de terceiros, você checa na fase de teste de integração, OK ?

Todos foram feitos por mim. Então sobra todos os testes igualmente para mim hahaha =P

@Kenobi, massa ! Vou anotar aqui para dar uma olhada nessa ferramenta

@peczenyj, é em cadeia mesmo !
Huum ! Esse esquema em cadeia para testar funcionabilidade parece show ! Além deles faltariam os testes de code coverage e aceitação =P

Realmente testar WebServices é mais complexo do que sistemas “pseudolocais” hahahaha =P

Um problema que eu costumo encontrar é que testando funcionabilidade em WebService (chamam de blackbox, é isso ?) geralmente o acesso aos dados é inevitável ! Fiz uns esquemas no bootstrap do sistema de testes para evitar isso, mas mesmo assim, acabei precisando de um database mock que é truncado cada vez que o teste roda - o drop é automático, claro =P

[]'s

Se os testes são dificeis algo esta complicado demais na sua arquitetura.

Vou dar um exemplo mais simples: eu trabalhei em um sistema (Rails) que acessava uma API REST, fazia 3 GETs diferentes e, então, fazia um POST em outro sistema.

Eu testava sobre todas as combinações usando FakeWeb, uma hora um dos GETs recebia um server error 500, outra hora o POST respondia com sucesso, etc. Eu controlava estes pontos de acesso e sabia que todos os caminhos estavam sendo exercitados. No teste final tudo era posto para funcionar e, encontrado algum problema, geralmente ou a API REST me retornava algo errado ou o outro sistema fazia algo indevido mas o meio tava garantido.

A vantagem do Rails era a database de DEV, que eu dropava a vontade, carregava os dados esperados, etc. O sistema ficou bem robusto no fim das contas, exceto quando vendorizamos algumas gems mas isso é outro assunto

peczenyj:

Se os testes são dificeis algo esta complicado demais na sua arquitetura.

Vou dar um exemplo mais simples: eu trabalhei em um sistema (Rails) que acessava uma API REST, fazia 3 GETs diferentes e, então, fazia um POST em outro sistema.

Eu testava sobre todas as combinações usando FakeWeb, uma hora um dos GETs recebia um server error 500, outra hora o POST respondia com sucesso, etc. Eu controlava estes pontos de acesso e sabia que todos os caminhos estavam sendo exercitados. No teste final tudo era posto para funcionar e, encontrado algum problema, geralmente ou a API REST me retornava algo errado ou o outro sistema fazia algo indevido mas o meio tava garantido.

A vantagem do Rails era a database de DEV, que eu dropava a vontade, carregava os dados esperados, etc. O sistema ficou bem robusto no fim das contas, exceto quando vendorizamos algumas gems mas isso é outro assunto :)

Mais complexo que eu digo é que há mais tipos de testes que precisam serem feitos para validar e tal. =D
O sistema tem vários pontos, mas estão bem (pelo menos hoje eu acho) simples de trabalhar.

O esquema do database dev para poder dropar eu também tenho aqui. É gerenciado pelo próprio Test Engine, ou seja, ao iniciar o teste ele dropa tudo e coloca as informações básicas essenciais via arquivo de configuração - um fixture, assim digamos.

Vou preparar esses testes conforme você me recomendou. Pegando os pontos eu dou um feedback para atualizar vocês, pedir dicas e também auxiliar a galere do fórum aqui =D

[]'s

@hlegius

Para fazer os testes via SOAP, você pode utilizar o soapUI.

Acredito que ele conseguirá atender bem a sua necessidade, ele é bastante usado para fazer testes de WS.

Abraços!

P.S.: Em relação a nomenclatura seria um teste de caixa cinza.

Fabrício Ferrari de Campos, CBTS, CTFL
Blog: qualidadebr.wordpress.com
Twitter: twitter.com/FabricioFFC
LinkedIn: br.linkedin.com/in/fabricioferraridecampos

FabricioFFC:

P.S.: Em relação a nomenclatura seria um teste de caixa cinza.

Huum ! Caixa cinza eu nem conhecia hahaha ! valeu pelo link =D

[]'s