Skip to main content

[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.


Back to the top