Shibboleth Developers

[Walter Hoehn <>]

On Aug 29, 2005, at 12:43 PM, Tom Scavo wrote:
> I want to make another attempt to clarify a timing issue with respect
> to extension testing.  I will argue that "post-install" testing is
> just as valuable, and perhaps more valuable than "pre-install"
> testing.
>
> Right now extension unit tests are being run pre-install.  I claim
> these tests are primarily useful for developers.  If an extension is
> routinely unit tested while it is being developed and as it goes out
> the door, there is really no need for a deployer to run these tests
> again as part of the install process.  However, a VERY useful addition
> to the install process would be automatic post-install testing, that
> is, after files have been moved into place by the installer.  Let me
> give a specific example.


Right.  The entire test suite and associated machinery are intended  
to be used solely by developers.  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.  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.


> The GridShib extension has a config file on the classpath something  
> like this:
>
> dp.home=$IDP_HOME$
> sp.home=$SP_HOME$
> ext.name=$EXTENSION_NAME$
> gridshib.path=$IDP_HOME$/etc/$EXTENSION_NAME$/mappings
>
> At install time, the placeholders are replaced and the config file is
> bundled with the JAR.  At this point, we would like to run a series of
> tests that of course depend on this config file to be available at a
> specific location on the classpath.
>
> Since the install process runs tests "pre-install", this is not at all
> straightforward.  As a workaround, we've included the following test
> resource on the classpath:
>
> idp.home=C:/shibboleth-idp-1.3
> sp.home=C:/shibboleth-sp-1.3
> ext.name=gridshib-idp
> gridshib.path=C:/shibboleth-idp-1.3/etc/gridshib-idp/mappings
>
> This works fine for developer testing but it's practically worthless
> for end user testing since the paths are hardcoded into the test
> config file.  Consequently, the GridShib extension must be distributed
> with test.ext=false.
>
> So what is needed, I think, are two separate rounds of testing, one
> "pre-install" and the other "post-install".  The pre-install tests are
> run by the developer ('ant compile').  The post-install tests are run
> by the install process AFTER the extension has been installed,
> depending on the value of test.ext.  There may be a better way to do
> this, but some kind of post-install testing is definitely needed IMO.