Shibboleth Developers

[Walter Hoehn <>]

Huh?  We must be working from a completely different definition of  
the phrase "unit testing".  The purpose of the shibboleth unit tests  
is to verify the correctness of the shibboleth code.  The extension  
mechanisms provides a convenient way of packaging like tests for  
extensions.  There was never any intention for the process to support  
configuration validity checking or production status verification.

-Walter


On Aug 29, 2005, at 9:26 PM, Tom Scavo wrote:

> On 8/29/05, Walter Hoehn 
> <>
>  wrote:
>
> > I do agree that the use case you
> > put forth below is valid, but I don't think that we'd want to hook
> > that sort of thing into the shibboleth build process.
>
> I don't see why not.  Part of the install process is the expansion of
> placeholders $IDP_HOME$, $SP_HOME$, and $EXTENSION_HOME$ (a very
> worthwhile feature!).  This needs to happen *before* the unit testing.
>  Then a unit test will find an actual resource on the classpath and
> can test that the plugin is consuming the resource properly.  As it
> is, macro expansion occurs *after* unit testing and so actual
> resources are not available to the unit tests.  The only workaround is
> to create a phoney resource but as I illustrated earlier, this is of
> no use to the deployer at install time.

> I need to wrap a unit test around every piece of data a deployer can
> modify prior to running 'ant install'.  There are two sources of bugs
> that can be introduced in this way, the plugin's build.properties file
> and resources on the classpath.  The extension framework already
> validates the build.properties file so it's up to the extension
> developer to double-check the resources on the classpath.
>
> This is an issue precisely because placeholders are being expanded on
> resources.  All I'm asking for is that this occur *before* unit tests,
> which I don't think is unreasonable.
>
> > If you want to
> > check configuration validity, you should probably include a shell
> > script loader that can be run without even having the install source
> > available.
>
> Of course this can be done, but by that time a faulty installation has
> already occurred.  It would be better if these problems were snagged
> earlier in the process.
>
> Tom