Shibboleth Developers

["Howard Gilbert" <>]

I just checked in the Mockrunner stuff, including an example test case that
does an attribute-push SSO and feeds the resulting SAMLResponse into the
session creation layer of the SP and OpenSAML. Look it over.

Normally I would recommend a distributed package that is documented and
supported, but this is a pretty thin layer and its "documentation" is almost
useless. However, it does support both the Servlet and Filter API and
simulates all the control blocks (request, response, contexts, configs, ...)
which sounds a lot more comprehensive than what you describe. I need a lot
of this other stuff to properly test the Filter. 

> -----Original Message-----
> From: Will Norris 
> [mailto:]
> Sent: Tuesday, August 23, 2005 10:54 AM
> To: 
> 
> Subject: Re: Integration JUnit testing
> 
> 
> On Aug 22, 2005, at 2:16 PM, Howard Gilbert wrote:
> > JUnit testing of the Shibboleth SP can be difficult because of
> > several things:
> >
> > <snip>
> 
> 
> When I started working with Walter, one of the first projects he had
> me do was to create a mechanism to do blackbox unit testing on the
> IdP code.  After looking at Cactus and Mock Objects, I ended up going
> with an Embedded Tomcat instance with a custom protocol handler.
> This custom handler bypasses sockets altogether and instead
> publicizes the process() method so that fabricated HTTP requests can
> be injected directly into the servlet for processing.  It was working
> great in 1.2.1, but I didn't have time to verify it against 1.3 so it
> was never committed to CVS.  Since this type of blackbox testing is
> obviously being done on both the IdP and SP side, perhaps we should
> attempt to standardize our methods some way.  thoughts?
> 
> -will
> 
> 
> --
> Will Norris
> Information Technology
> The University of Memphis
>