juddi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex O'Ree" <spyhunte...@gmail.com>
Subject Re: TCK Productization Strategy
Date Wed, 05 Jun 2013 20:32:58 GMT
I'm not suggesting that we remove anything. This is an "in addition
to" function that would support performing tck based testing without
the need for internet access, maven, and the full source tree.

On Tue, Jun 4, 2013 at 12:37 PM, Kurt T Stam <kurt.stam@gmail.com> wrote:
> 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> 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> 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>
>>>>> 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
>>>>>>> will trigger the tests, the configuration loads from within the
>>>>>>> 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
>>>>>>> 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>
>>>>>>> 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
>>>>>>>>> Currently, all Unit Test cases (/src/test) are within
uddi-tck, and
>>>>>>>>> all setup and configure the code is in uddi-tck-base
>>>>>>>>> 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
>>>>>>>>> uddi-tck, then use JUnitCore to execute them. In addition,
>>>>>>>>> the
>>>>>>>>> configuration loading bits to load files from disk instead
of from
>>>>>>>>> within the jar file. This requires the test classes (src/test)
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> 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
>>>>>>>>> Similar to the surefire test reports, but more user friendly.

View raw message