shibboleth-dev - Re: extension unit testing
Subject: Shibboleth Developers
List archive
- From: Tom Scavo <>
- To:
- Subject: Re: extension unit testing
- Date: Fri, 26 Aug 2005 18:07:37 -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=lfSR7E1hKzyT0RtVnNFCIPTlyZQ9Pf9OHQcXR6wSw3IGW8bugjedq03xja0K+npeoFU2OXxY6LQCXLBf7zzl92p77/NJyOB1/psBEWVxoCiJj4xA1KnFkptgoozIo26aO9mlMgI+ogC8y19M2ffgt+V8bSD5ZWNNeG1vAJCW41U=
On 8/26/05, Chad La Joie
<>
wrote:
>
> No, I'm talking about a post-installation test that I can run after I
> make config changes to make sure I have totally messed something up.
Oh, in that case GridShib has only two post-install touch points:
1) Metadata (gridshib-sp-metadata.xml)
2) Name mappings
The metadata file is an ordinary metadata file, so you already know
how that works. As far as the name mappings are concerned, the plugin
responds to changes in the name mapping file(s) automatically. Right
now, there is only one name mapping file. Post-beta the plugin will
support multiple name mapping files in multiple locations (controlled
by a path-like property). Moreover, we will supply a ProtocolHandler
that allows users to add a DN-principalName pair to the map file, so
there's no admin maintenance required there either. So apart from
adding EntityDescriptor elements to the metadata file, there's nothing
to configure or maintain.
> Which, it sounds like, isn't what you're talking about. So, this was
> just a misunderstanding on my part.
Right, we're building tests that test the GridShib deployment. I use
these tests for development purposes and admins will use them to
validate their one-time configuration steps. They only need to run
these tests once for any given deployment.
> >>So what you could do is create such a script and place it in the
> >>gridshib/bin directory of your source tree. Then just have that script
> >>invoke the post-deployment test classes.
> >
> > Like the command-line tools currently distributed in bin? Okay, but I
> > was thinking an ant script would be better since I need to invoke
> > tasks in extension-build.xml.
>
> Why would you need to call in to extension-build.xml.
Mostly for development purposes (like the 'ant compile' trick you told
me about yesterday) but also for the config validation tests mentioned
above.
> I just want a
> tool that checks stuff after things are installed everything in that
> build file happens before installation.
I'm still not understanding your needs, but keep trying and I'll supply it.
:-)
Tom
- Re: extension unit testing, (continued)
- Re: extension unit testing, Tom Scavo, 08/22/2005
- Re: extension unit testing, Chad La Joie, 08/22/2005
- Re: extension unit testing, Tom Scavo, 08/26/2005
- Re: extension unit testing, Chad La Joie, 08/26/2005
- Re: extension unit testing, Tom Scavo, 08/26/2005
- Re: extension unit testing, Walter Hoehn, 08/26/2005
- Re: extension unit testing, Tom Scavo, 08/26/2005
- Re: extension unit testing, Chad La Joie, 08/26/2005
- Re: extension unit testing, Tom Scavo, 08/26/2005
- Re: extension unit testing, Chad La Joie, 08/26/2005
- 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, Chad La Joie, 08/22/2005
- Re: extension unit testing, Tom Scavo, 08/22/2005
Archive powered by MHonArc 2.6.16.