soaplite-devel

Re: [Soaplite-devel] SOAP::Lite development - next release

[David B. <Dav...@qm...>]

Why not make the test suite have built-in test services, and completely a=
void external dependancies altogether. =20

If it was me, I'd make a "fake soap server" testing tool, that only knows=
 how to respond to one specific request with one specific "canned" respon=
se, and (in order to test alternate functionalities, I'd make the "canned=
 responses" exactly match those currently given by services like weather,=
 google, etc.   THis way, you get the tests against "external" systems (v=
ia their canned "known responses" saved to a local configuration) , and d=
on't rely on the 4external systems themselves being up.   It also means t=
hat the tests work behind big/secure firewalls and on off-line systems.

Buzz.

-----Original Message-----
From: soa...@li...
[mailto:soa...@li...]On Behalf Of Robert
Landrum
Sent: Thursday, 11 October 2007 12:36 AM
To: Matthew Runo
Cc: soaplite-devel
Subject: Re: [Soaplite-devel] SOAP::Lite development - next release


Matthew Runo wrote:
> Yes, the test suite ran upon install has been failing for some time =20
> now. I've been ignoring it, and --force installing. I vote to remove =20
> it - add in a couple you know are live and go for it.
>=20

That's sort of the problem.  What is live, and what is going to be live=20
in perpetuity.

It's a trivial matter to test against local services, but more often=20
than not, I find services written in Java, C#, etc, to be incompatible=20
with the current SOAP::Lite implementation... And that just within my=20
organization.  :(

I found this...  http://www.xmethods.net/ilab/

I haven't looked at the test suite, so I'm not sure how many these are=20
actually being tested.

Rob

-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
_______________________________________________
Soaplite-devel mailing list
Soa...@li...
https://lists.sourceforge.net/lists/listinfo/soaplite-devel


The message and any attachment is confidential and may be privileged or o=
therwise protected from disclosure. If you have received it by mistake pl=
ease let us know by reply and then delete it from your system; you should=
 not copy the message or disclose its contents to anyone.

Re: [Soaplite-devel] SOAP::Lite development - next release

[Robert L. <rla...@ao...>]

David Bussenschutt wrote:
> Why not make the test suite have built-in test services, and completely avoid external dependancies altogether.  
> 
> If it was me, I'd make a "fake soap server" testing tool, that only knows how to respond to one specific request with one specific "canned" response, and (in order to test alternate functionalities, I'd make the "canned responses" exactly match those currently given by services like weather, google, etc.   THis way, you get the tests against "external" systems (via their canned "known responses" saved to a local configuration) , and don't rely on the 4external systems themselves being up.   It also means that the tests work behind big/secure firewalls and on off-line systems.
> 

That works for testing the parsing of the responses from those external 
services, but does not test the formatting of the original request. 
That's actually an area that seems to be a bigger problem, at least 
looking at the interop.soaplite.com page.  A cursory glance seems to 
indicate that there are issues in the formatting of our initial 
requests...  of course this is a ancient version.

Just throwing out an idea...

What if we attempt to connect to soaplite.com for a list of interop 
tests?  If the connection fails, we get nothing to test and nothing to 
fail, which seems like it mitigates (to a degree) the firewall issue. 
If a response is received, the interop test services can be parsed out 
and tested.  This would mean that even when the interop services change, 
we don't need to release a new version to correct the issue.

Re: [Soaplite-devel] SOAP::Lite development - next release

[Paul K. <pau...@ya...>]

Robert,

> What if we attempt to connect to soaplite.com for a list of interop
> tests?  If the connection fails, we get nothing to test and nothing
> to fail, which seems like it mitigates (to a degree) the firewall
> issue. 

This is actually exactly how it was done previously (and probably
still is). If the connection fails then the test is skipped (for most
if not all external tests). There is also a set of tests that runs on
soaplite.com; it can be modified/expanded to match our requirements.

Paul.

--- Robert Landrum <rla...@ao...> wrote:

> David Bussenschutt wrote:
> > Why not make the test suite have built-in test services, and
> completely avoid external dependancies altogether.  
> > 
> > If it was me, I'd make a "fake soap server" testing tool, that
> only knows how to respond to one specific request with one specific
> "canned" response, and (in order to test alternate functionalities,
> I'd make the "canned responses" exactly match those currently given
> by services like weather, google, etc.   THis way, you get the
> tests against "external" systems (via their canned "known
> responses" saved to a local configuration) , and don't rely on the
> 4external systems themselves being up.   It also means that the
> tests work behind big/secure firewalls and on off-line systems.
> > 
> 
> That works for testing the parsing of the responses from those
> external 
> services, but does not test the formatting of the original request.
> 
> That's actually an area that seems to be a bigger problem, at least
> 
> looking at the interop.soaplite.com page.  A cursory glance seems
> to 
> indicate that there are issues in the formatting of our initial 
> requests...  of course this is a ancient version.
> 
> Just throwing out an idea...
> 
> What if we attempt to connect to soaplite.com for a list of interop
> 
> tests?  If the connection fails, we get nothing to test and nothing
> to 
> fail, which seems like it mitigates (to a degree) the firewall
> issue. 
> If a response is received, the interop test services can be parsed
> out 
> and tested.  This would mean that even when the interop services
> change, 
> we don't need to release a new version to correct the issue.
> 
> 
> 
>
-------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> 



       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  

Re: [Soaplite-devel] SOAP::Lite development - next release

[Martin K. <mar...@fe...>]

Hi there,

thanks for all your remarks - I think I'm going to use the URL Robert
found for interop tests. Even if we would use soaplite.com, I guess
there won't be too many volunteers for keeping a bunch of different SOAP
servers (like listed on http://www.xmethods.net/ilab/) up and running.

For a starter, I'll just skip the test that fail for external reasons
(i.e. because the SOAP server queried does not return the expected
result but something else), and add improving the test suite to my list
of tasks.

Martin

Am Donnerstag, den 11.10.2007, 11:20 -0700 schrieb Paul Kulchenko:
> Robert,
> 
> > What if we attempt to connect to soaplite.com for a list of interop
> > tests?  If the connection fails, we get nothing to test and nothing
> > to fail, which seems like it mitigates (to a degree) the firewall
> > issue. 
> 
> This is actually exactly how it was done previously (and probably
> still is). If the connection fails then the test is skipped (for most
> if not all external tests). There is also a set of tests that runs on
> soaplite.com; it can be modified/expanded to match our requirements.
> 
> Paul.
> 
> --- Robert Landrum <rla...@ao...> wrote:
> 
> > David Bussenschutt wrote:
> > > Why not make the test suite have built-in test services, and
> > completely avoid external dependancies altogether.  
> > > 
> > > If it was me, I'd make a "fake soap server" testing tool, that
> > only knows how to respond to one specific request with one specific
> > "canned" response, and (in order to test alternate functionalities,
> > I'd make the "canned responses" exactly match those currently given
> > by services like weather, google, etc.   THis way, you get the
> > tests against "external" systems (via their canned "known
> > responses" saved to a local configuration) , and don't rely on the
> > 4external systems themselves being up.   It also means that the
> > tests work behind big/secure firewalls and on off-line systems.
> > > 
> > 
> > That works for testing the parsing of the responses from those
> > external 
> > services, but does not test the formatting of the original request.
> > 
> > That's actually an area that seems to be a bigger problem, at least
> > 
> > looking at the interop.soaplite.com page.  A cursory glance seems
> > to 
> > indicate that there are issues in the formatting of our initial 
> > requests...  of course this is a ancient version.
> > 
> > Just throwing out an idea...
> > 
> > What if we attempt to connect to soaplite.com for a list of interop
> > 
> > tests?  If the connection fails, we get nothing to test and nothing
> > to 
> > fail, which seems like it mitigates (to a degree) the firewall
> > issue. 
> > If a response is received, the interop test services can be parsed
> > out 
> > and tested.  This would mean that even when the interop services
> > change, 
> > we don't need to release a new version to correct the issue.
> > 
> > 
> > 
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a
> > browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > Soaplite-devel mailing list
> > Soa...@li...
> > https://lists.sourceforge.net/lists/listinfo/soaplite-devel
> > 
> 
> 
> 
>        
> ____________________________________________________________________________________
> Moody friends. Drama queens. Your life? Nope! - their life, your story. Play Sims Stories at Yahoo! Games.
> http://sims.yahoo.com/  
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> Soaplite-devel mailing list
> Soa...@li...
> https://lists.sourceforge.net/lists/listinfo/soaplite-devel
>