[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [jakartaee-platform-dev] TCK tests in the same repo as API andSpec
|
Andy Guibert wrote on 2/20/20 11:52 AM:
Now we seem to be going in circles... To recap the
relevant points:
1) How do we create overall platform TCK and how does it
fit together?
> In the same way that CDI and BeanValidation did it
for JavaEE 8 / JakartaEE 8
They didn't. That's the point. That's what we want to avoid.
2) What test framework? What technologies?
> Arquillian+JUnit. These technologies are well-tested
and widely understood in the community, and are perfectly
capable of doing more complex testing such as pulling in
DBs, mail servers, or other external resources. CDI and
BeanVal are reasonably complex specs/TCKs and are already
using Arquillian.
How do we teach Arquillian to run the
existing test cases? Or how do we convert the existing test cases
so that Arquillian can run them? And either way, how do we assure
ourselves that the result has the same pass/fail characteristics
as the original?
3) [From
the meeting minutes] Requirement – allow the use of the
existing TCK tests themselves. If all of the TCK tests
need to be modified just to become part of this new
infrastructure, the process will die. We need the ability
to incorporate existing TCK tests.
>
The conversion can be done on a spec-by-spec case. For
example, everything would work fine if just JSON-B
migrated to the "external TCK" way and all other specs
remained as-is. Also, the conversion could be all-in-one
or partial. For JSON-B I did an all-in-one conversion,
meaning I took _all_ existing TCK tests and converted them
to Arquillian+JUnit so now JSON-B TCK tests don't use
JavaTest at all. Personally I think per-spec all-in-one
conversion is best so there is only ever 1 framework per
spec, but each spec could have the flexibility to do what
they want.
This is the process that the notes claim will die. Depending on
each spec project to convert all of their tests to a new framework
just won't happen. You might end up with 10 specs fully converted
and 27 specs still using the old framework. If old and new can
coexist, that might be fine. Even if we had to run two completely
separate TCK frameworks, that might be acceptable. I'd like to hear
what others think about this entire process of converting tests to a
new framework, whether it needs to be done automatically, whether it
can be done manually and incrementally, etc.