shibboleth-dev - Re: extension unit testing
Subject: Shibboleth Developers
List archive
- From: Tom Scavo <>
- To: Walter Hoehn <>
- Cc:
- Subject: Re: extension unit testing
- Date: Mon, 29 Aug 2005 22:26:17 -0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=p0DkXykGNVJx3dlCHXqmfjcCK/ZgobrwwvsfqUJNXVQ+wOkAnxVxqgJSNKHXT+8kfJXglYd+/yhDx6gt8SD1g1x04XM4q+5cEdzI4QWpK7N865tZXCc7ldCD0SZ3oFjtHNO7uZuISV7qAMkDgkk4tzEPQyMErAXo/00ylEmnoXU=
On 8/29/05, Walter Hoehn
<>
wrote:
>
> 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...
>
> Right. The entire test suite and associated machinery are intended
> to be used solely by developers.
Well then, why offer test.ext as an option?
> 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
- Re: extension unit testing, (continued)
- Re: extension unit testing, Chad La Joie, 08/29/2005
- Re: extension unit testing, Chad La Joie, 08/29/2005
- Re: extension unit testing, Tom Scavo, 08/29/2005
- Re: extension unit testing, Chad La Joie, 08/29/2005
- Re: extension unit testing, Tom Scavo, 08/29/2005
- Re: extension unit testing, Tom Scavo, 08/29/2005
- Re: extension unit testing, Tom Scavo, 08/29/2005
- Re: extension unit testing, Chad La Joie, 08/29/2005
- Re: extension unit testing, Tom Scavo, 08/29/2005
- Re: extension unit testing, Walter Hoehn, 08/29/2005
- Re: extension unit testing, Tom Scavo, 08/29/2005
- Re: extension unit testing, Walter Hoehn, 08/30/2005
Archive powered by MHonArc 2.6.16.