You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Thomas Sauzedde <ts...@miyowa.com> on 2008/12/19 15:29:57 UTC

What is the best way to test a client business ?

Hi everybody,

To cut a long story short, I need an advice for testing (unitary test
with JUnit / TestNG & Easymock) a CXF client.

The context :
- I'm working on a SOAP client (CXF of course) with asynchronous
response handling (Future <?> way)
- I cannot "modify" the server nor the WSDL (I'm only on the client side)
- I'm self confident in CXF ;-), I don't want to test all the "plumbing"
..., I'd like to test my business "only"
- I'm using a CI server (Hudson) and I'd like to avoid launching an http
server to unitary test my client.

What I've imagined is to "inject" some pre-formated response from stored
xml files (pre-formatted SOAP messages).
Those SOAP messages may contain "normal" responses or SOAP fault responses.

>From the CXF tests, I'm wondering if the local transport is the way to
do this ...
In this case, for what I've understood so far, I need to implement the
server side but it looks a bit overweighted to me.

Could someone tell me the best way to test my client ?

Thanks in advance

--
Tom



Re: What is the best way to test a client business ?

Posted by Thomas Sauzedde <th...@gmail.com>.
On Fri, Dec 19, 2008 at 7:19 PM, Ben Dean <Be...@ontariosystems.com>wrote:

> I would recommend SoapUI. The free version works pretty decently but the
> SoapUI Pro version can do some useful things such as using groovy scripts.
> Check it out at http://www.soapui.org. About half-way down the page they
> have links to run the programs with Java Web Start (although you need to buy
> a license to use the Pro version).
>
> -- ben


Thank you for this answer.

I'm already using soapUI to debug my client or to easily "capture" responses
from the real server.
BTW, in my previous email, the responses I already have, come from what
soapUI shows ;-)

But this is not an acceptable solution, because in this case soapUI acts
like a "normal" http server and this is not possible to me to have such a
thing on my continuous integration server :-(

I would prefer an autonomous (JUnit / TestNG / Easymock) way to test my
client.

But anyway, thank you again for your answer

--
Tom

RE: What is the best way to test a client business ?

Posted by Ben Dean <Be...@OntarioSystems.com>.
I would recommend SoapUI. The free version works pretty decently but the SoapUI Pro version can do some useful things such as using groovy scripts. Check it out at http://www.soapui.org. About half-way down the page they have links to run the programs with Java Web Start (although you need to buy a license to use the Pro version).

-- ben

> -----Original Message-----
> From: Thomas Sauzedde [mailto:tsauzedde@miyowa.com]
> Sent: Friday, December 19, 2008 9:30 AM
> To: users@cxf.apache.org
> Subject: What is the best way to test a client business ?
> 
> Hi everybody,
> 
> To cut a long story short, I need an advice for testing (unitary test
> with JUnit / TestNG & Easymock) a CXF client.
> 
> The context :
> - I'm working on a SOAP client (CXF of course) with asynchronous
> response handling (Future <?> way)
> - I cannot "modify" the server nor the WSDL (I'm only on the client
> side)
> - I'm self confident in CXF ;-), I don't want to test all the
> "plumbing"
> ..., I'd like to test my business "only"
> - I'm using a CI server (Hudson) and I'd like to avoid launching an
> http
> server to unitary test my client.
> 
> What I've imagined is to "inject" some pre-formated response from
> stored
> xml files (pre-formatted SOAP messages).
> Those SOAP messages may contain "normal" responses or SOAP fault
> responses.
> 
> From the CXF tests, I'm wondering if the local transport is the way to
> do this ...
> In this case, for what I've understood so far, I need to implement the
> server side but it looks a bit overweighted to me.
> 
> Could someone tell me the best way to test my client ?
> 
> Thanks in advance
> 
> --
> Tom
> 

Attention: This message and all attachments are private and may contain
information that is confidential and privileged. If you received this
message in error, please notify the sender by reply email and delete
the message immediately.