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 Tue, 04 Jun 2013 16:37:05 GMT
Hmm I think it would be better to keep things standard and use the unit 
tests framework and maven.

On 6/4/13 9:33 AM, Alex O'Ree wrote:
>
> That's the idea. I think its possible but we'll need to find a way to 
> identify test classes without knowing a priori. This will make it more 
> robust and hands off. I'll see what i can do
>
> On Jun 4, 2013 8:28 AM, "Kurt T Stam" <kurt.stam@gmail.com 
> <mailto:kurt.stam@gmail.com>> wrote:
>
>     That way we get all the reporting options for free?
>
>     On 6/3/13 11:32 AM, Alex O'Ree wrote:
>
>         We don't require maven or the source code to run jUDDI, why
>         should the
>         TCK require any of those?
>
>         Assuming we don't have those, there's no class that I know of that
>         will start the tests from the command line. What it should be
>         something as simple as this:
>         java -jar uddi-tck.jar <path to config file>
>
>         On Mon, Jun 3, 2013 at 10:15 AM, Kurt T Stam
>         <kurt.stam@gmail.com <mailto:kurt.stam@gmail.com>> wrote:
>
>             On 6/3/13 10:08 AM, Alex O'Ree wrote:
>
>                 Lots.
>
>                 1) we don't distribute maven, the source code and all
>                 of the other
>                 dependencies with the client jar packages
>
>             Hmm. I don't think having to download maven is an issue,
>             and if you really
>             feel that strongly I guess we cold add maven (and java?)
>             to the distro, one
>             needs somekind of build tool. I'd rather stick with maven.
>
>                 2) it won't work if you're on an isolated network
>
>             The -O option should fix that.
>
>                 3) is a full source code checkout really necessary in
>                 order to
>                 validate that someone else's product is valid?
>
>             No it should be running of the code we ship in the
>             distribution.
>
>                 The goal here is to make the tck a usable product
>                 without a full up
>                 dev environment, maven, or network connectivity. Maven
>                 is great for
>                 some things, not for all things
>
>                 On Mon, Jun 3, 2013 at 10:05 AM, Kurt T Stam
>                 <kurt.stam@gmail.com <mailto:kurt.stam@gmail.com>> wrote:
>
>                     What's wrong with running maven?
>
>
>                     On 6/3/13 9:53 AM, Alex O'Ree wrote:
>
>                         Even if we include the unit tests, there's no
>                         void main function that
>                         will trigger the tests, the configuration
>                         loads from within the jar,
>                         not from a user definable location, and
>                         running junit tests from
>                         within your own app is a bit tricky (unless we
>                         know we're never going
>                         to add another test ever again, thus the
>                         reflection).
>
>                         On Mon, Jun 3, 2013 at 9:47 AM, Kurt T Stam
>                         <kurt.stam@gmail.com
>                         <mailto:kurt.stam@gmail.com>> wrote:
>
>                             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
>                             mistake..
>                             No?
>
>                             Cheers,
>
>                             --Kurt
>
>
>                             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.
>
>
>


Mime
View raw message