juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kurt T Stam <kurt.s...@gmail.com>
Subject Re: TCK Productization Strategy
Date Mon, 03 Jun 2013 13:47:51 GMT
Maybe I'm missing the point, but why can't they run the way they are now?
All we have to do is to add the uddi-tck-test.jar, which for omitted by 



On 6/2/13 12:57 PM, Alex O'Ree wrote:
> Relevant Tickets:
> JUDDI-314 Create a juddi-client-bundle-3.0.0 with jar, source and
> javadocs for juddi-client and uddi-ws
> JUDDI-583 Productize the TCK test suite
> I'm attempting to formulate a plan to turn the UDDI TCK into both a
> testing platform for jUDDI (as it is now) and be able to run the test
> suites as a standalone program (without requiring a full checkout).
> Currently, all Unit Test cases (/src/test) are within uddi-tck, and
> all setup and configure the code is in uddi-tck-base (/src/main)
> In order to facilitate this change, I've came up with an idea and was
> wondering if anyone else had a better one before I devote time and
> effort into it.
> 1) Use reflection to identify all classes with test cases from
> uddi-tck, then use JUnitCore to execute them. In addition, rework the
> configuration loading bits to load files from disk instead of from
> within the jar file. This requires the test classes (src/test) to be
> included in the udid-tck jar file.
> 2) Refactor all existing test cases to uddi-tck/src/main and rework
> the actually uddi-tck/src/test classes to call the code from src/main.
> I only think this should be required if for some reason the test
> classes can't be included with the tck jar file see (JUDDI-314). Then
> use some kind of reflection to find all test cases and execute them.
> In either case, it would be nice to have a formatted xml output which
> identifies all the tests cases that failed and the relevant output.
> Similar to the surefire test reports, but more user friendly.

View raw message