Shibboleth Developers

["Howard Gilbert" <>]

> Perhaps I'm misunderstanding what this tests, but is this not testing
> basically the same thing as the blackbox IdP stuff checked in last
> month? (tests/edu.i2.middleware.shibboleth.idp.(AA|SSO)Test).  That
> DOES contain a fairly exhaustive set of tests.  Just "Run As -> Junit
> Test".

Because this not only does an SSO, it also consumes it, creates a session,
passes the data over to the filter, and checks that the HTTP Headers map
correctly. It runs everything from the logon to the Resource API.

Given the tendency of Assertions to timeout if not used immediately, and the
requirement to digitally sign the timestamp, the only easy way to generate
test data for the SP to consume is to run the IdP to get it. Once that
became a requirement, the idea of instantiating the entire system under
JUnit instead of Tomcat became attractive. 

> More of a simple project management question, but what was the
> rationale behind /testresources as opposed to keeping everything
> together in /data ?

The current support allows configuration files to be either in an absolute
local disk path (rewritten by the install process) or else in a resource. Of
course, if you are building a Unit Test you can read files from a path
relative to the current directory. However, if you are running the entire
system as designed, then you either have to start every test by rewriting
all the configuration files, or else the configuration has to be a Resource
in the classpath. The /data stuff was not designed to be a Resource (or it
would already be a source directory), so I created a separate and clusters
of internally consistent configuration files. 

Each /data file stands on its own, but the integration test has to
initialize an entire IdP, SP, and Filter.