shibboleth-dev - Re: extension unit testing
Subject: Shibboleth Developers
List archive
- From: Tom Scavo <>
- To:
- Subject: Re: extension unit testing
- Date: Mon, 29 Aug 2005 13:43:36 -0400
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=JGkjkLV5TmaTbe240L2jo28zzPvU6U3XME/eRpJh6i/6jD4PO2SmKt4gBWpCwkPa2zokhAcf2ilkCWEs0kqF2Uzmr3hpsaapsaWM8sCxl/ZW7TlUItYFqdjkBzBnEosw9IAwFtmS9Zj1UVvi0wxrgA5iiQJ5q9/hlz/zCL0eZQY=
On 8/29/05, Chad La Joie
<>
wrote:
>
> So, we should be all set.
Yes, thanks for being so responsive and working to make this process better.
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.
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.
Thanks,
Tom
- Re: extension unit testing, (continued)
- Re: extension unit testing, Tom Scavo, 08/26/2005
- Re: extension unit testing, Tom Scavo, 08/28/2005
- 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.