Tenho uma aplicação onde todo o acesso à ela é baseado em WebServices (SOAP). Eu pesquisei e vi que o modelo de testes adotado nestes casos é um teste para cada “método” acessível via WS.
Porém, meu code coverage retorna praticamente 0% uma vez que os testes efetuam as chamadas SOAP. Uma solução que encontrei seria criar também os testes chamando as classes diretamente, sem WebServices, mas não tenho tanta certeza quanto a sua aplicabilidade/utilidade.
Os senhores já passaram por alguma coisa do tipo ? Tem dicas ? =D
Sistema1 (invoca metodo via SOAP + …)----> Sistema2
Imagino os seguintes testes
Teste de código, isolando os sistemas, nos dois sistemas
Teste funcional no Sistema2 com um client de teste invocando todos os metodos e fazendo Coverage no Sistema2
Teste funcional no Sistema1 simulando o Sistema2 em todos os metodos e todas as respostas possiveis (incluindo mensagens de erro, etc).
Teste de integração full onde os sistemas efetivamente se falam.
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).
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.
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
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[/quote]
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 ?
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.
[quote=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 ?[/quote]
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
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
[quote=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 :)[/quote]
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
