batchee-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Romain Manni-Bucau <rmannibu...@gmail.com>
Subject Re: Approach for testing core 'jbatch' function leveraging test utilities?
Date Thu, 28 Aug 2014 11:13:45 GMT
if you mean jbatch/src/main/ it can be depending the amount of code.
Some part of batchee are not impl dependent (extensions and some
utility classes of batchee-test). Here duplication is generally
acceptable. If not - too much code - then we can make the part
explicitely dependent on batchee (for test module) but it should be
stated explicitely.

+1 for TCKs, that's more or less what we do everywhere (@apache I mean)


Romain Manni-Bucau
Twitter: @rmannibucau
Blog: http://rmannibucau.wordpress.com/
LinkedIn: http://fr.linkedin.com/in/rmannibucau
Github: https://github.com/rmannibucau


2014-08-28 12:36 GMT+02:00 Scott Kurz <skurz3@gmail.com>:
> Romain, Mark,
>
> Thanks for the replies and the welcomes !
>
> Mark, regarding the TCK, we are planning to open the TCK for public
> contributions
> as part of the jbatch project...shortly.   I hope to get around to this in
> the next few weeks.
>
> So if a bug happens to point to a notable TCK coverage gap, adding a TCK
> test would be
> an option and we'd be happy to have help contributing these tests.
>
> But I was still curious to hear where we'd add some additional non-TCK
> tests.
>
> Sounds like Romain is OK starting by duplicating some of the batchee-test
> classes .. in the core 'jbatch' module itself even?
>
> I'll next deliver a patch trying some approach for the next bug I had in
> mind from the RI:
> https://java.net/bugzilla/show_bug.cgi?id=5407
> (an NPE stopping not-yet-started partitions).
>
> Actually, regarding Mark's point, this could be a good TCK test candidate
> (or part of a set covering "incomplete" partitions).
>
> But also note it's a one-line null guard fix to the impl... so ideally it
> would be possible to commit fix + test without having to wait for a TCK
> update.
>
> Scott
>
>
>
>
>
>
>
>
> On Wed, Aug 27, 2014 at 8:10 AM, Mark Struberg <struberg@yahoo.de> wrote:
>
>> Hi Scott!
>>
>> Good to have you around!
>>
>> Would that probably be a candidate for a JBatch TCK enhancement?
>> It would be great if all the effort also would lead to improving the TCK.
>>
>> If the answer is yes, then how can we contribute to the TCK in a smart way?
>> Quite a few of us are JCP members on other EGs, so that part should be
>> fine too.
>>
>> LieGrue,
>> strub
>>
>>
>>
>>
>>
>> > On Wednesday, 27 August 2014, 13:38, Scott Kurz <skurz3@gmail.com>
>> wrote:
>> > > Hi, it's been interesting to spend some time looking around the BatchEE
>> > project and look at all the integrations and extensions that you've been
>> > adding !
>> >
>> > I'm hoping to start contributing here by fixing some problems I know have
>> > been inherited from the RI codebase.
>> >
>> > So say we have a test that involves a sequence like a
>> > start/stop/restart...and say it's designed to test something in the
>> > "core"
>> > function in the 'jbatch' module.
>> >
>> > The most obvious place based on existing tests would seem to me to put
>> the
>> > test itself in 'jbatch'.    However, it might be nice to leverage the
>> > batchee-test utilities.
>> >
>> > But batchee-test already has a dependency on jbatch (looks like because
>> it
>> > uses the JAXB model).
>> >
>> > Seems like we could either have a new module, "batchee-testcases" (or
>> > something) leveraging batchee-test.   Or another approach might be to
>> pull
>> > out the JAXB model into a separate module if that would allow jbatch to
>> > depend on batchee-test.
>> >
>> > What do you think?
>> >
>> > Thanks,
>> > Scott
>> >
>>

Mime
View raw message