Shibboleth Developers

[Chad La Joie <>]

Not that I'm against testing, but before anything else gets checked in 
I'd like us to figure out exactly what we're testing, how we're testing, 
and how we're implementing the tests.  We no have three separate testing 
sets; the jUnit tests, the tests that Will wrote, and the stuff that 
Howard recently checked in.  I don't think anyone has a good idea of 
what each one covers, or is meant to cover.

Personally I find each of the solutions proposed below less than 
appealing and I strongly agree with Walter that a separate project for 
the testing code is a bad idea.

So, what I'd like to see, is a new thread started, here on the dev list, 
that proposes a testing plan in a clear and concise manner.  Once we 
have a plan then we can figure out what needs to be done.

Howard Gilbert wrote:
> The current release of Mockrunner 0.3.6 now creates some JSP 2.0 objects
> that can be used for JSP testing. We don't currently use this, but the
> objects are created unconditionally. This requires some JSP 2.0 (EL) classes
> in the classpath. Possible solutions (in no particular order) are:
>
> Freeze on 0.3.5 and give up bug fixes and improvements. [I don't like this.]
>
> Change the Eclipse classpath (and any JUnit test classpath for the
> integration tests) to use current Servlet/JSP libraries and cross our
> fingers and promise not to use Servlet features not supported by the oldest
> release we claim to support.
>
> Run the current Servlet API JAR file first, but then add the JSP 2.0 JAR
> file second in the search path. [This works but was rejected on the last
> phone call as unacceptable. I keep it in just to be comprehensive.]
>
> Modify Mockrunner to fix the problem (comment out four lines we don't use),
> then use our version of Mockrunner instead of the real one. Won't be the
> first time we struggled with third party libraries. 
>
> Create one modified Mockrunner class source in our project test source with
> the fixes. It will come first in the classpath search and override the
> corresponding class in the 0.3.6 JAR. 
>
> Create a separate test case project dependent on the shib Java project but
> with its own classpath that uses the later Servlet library.
>
> I sorta like the last choice (separate project). The Integration tests
> aren't a standard part of the distribution, so having yet another odd
> project in the CVS isn't a problem for the newbie.

--
Chad La Joie             315Q St. Mary's Hall
OIS-Middleware           202.687.0124