search

unitsofmeasurement / unit-tck

JSR 385 - Technology Compatibility Kit (TCK)
Other
6 stars 5 forks source link

Could we use JUnit 5 in the TCK? #9

Closed keilw closed 4 years ago

keilw commented 6 years ago

JUnit 5 offers many new features, inspired by TestNG or otherwise. Could the JSR 385 TCK benefit from some of them?

otaviojava commented 6 years ago

That is a nice question. I have a plan to use it in the JNoSQL JSR in the future. I think so, once, that is just an update to the library. I am not sure about break the current TCK, maybe keep the old code and the new ones use JUnit 5.

keilw commented 5 years ago

I'll descope that from version 2. Although the @Tag annotation works somewhat similar in JUnit 5 and other filters like includePackage etc. exist the relation between profiles and groups (or tags) is not so trivial to rebuild, so I'd rather stay with TestNG for 2.0. There is not even a spec for Jakarta EE NoSQL because the whole process is rather tedious, so I doubt there's anything to reuse or learn from before Unit-API 2.0 goes Final? The SI reform in May is more important, so we could think of an iterative follow-up JSR like 2.0.1 or 2.1 in a while to address those things. If Java SE gets value types or other improvements the JSR will also adapt even if the Metric standard won't change in our lifetime ;-)

teobais commented 5 years ago

So, if I get it right, we (still) want to migrate our TCK to JUnit5, just like we did for Unit-API. I'll have a look at it.

keilw commented 5 years ago

Not for 2.0 please. The TCKs for Jakarta EE are supposed to be based on TestNG as of now, building on experience that influenced this JSR and TCK (originally inspired by CDI and Money JSR) so as long as there's no significant move of Jakarta EE or other specs to JUnit 5, let's postpone that until the time comes.

keilw commented 5 years ago

We don't have to close it, it's just not relevant for 2.0 I marked it wontfix for the time being.

teobais commented 5 years ago

Ok, great; then indeed, the wontfix label serves best our case.

keilw commented 5 years ago

I added deferred similar to the API repo and others. Same for #11. This TCK is still meant to run with Java 8 as a minimal version, a future version would require Java 9, 11 or higher which is where we could revisit a CLI like JShell.

teobais commented 4 years ago

We're currently further than 2.0.

Is there still a desire to update our tck to JUnit5?

keilw commented 4 years ago

I think this is already applied, but at least before Jakarta EE 10 integration we'll have to revisit that if it works with the Jakarta EE platform? Since at least Jakarta Inject is also based on JUnit (4 AFAIK) there should be ways to do that, so will close this ticket here now.

keilw commented 4 years ago

Sorry I thought it was NoSQL but better to keep it closed and revisit it if a new major update to this JSR like 2.0 comes up.

otaviojava commented 4 years ago

IMHO: JUnit has several features that make easy to create test and also to define dependency as a test smoothly. Those features make sense, and it fits perfectly to the TCK.

keilw commented 4 years ago

But we don't need a new TCK here for quite a while. If a new JavaMoney JSR gets created, we might explore it there also based on learnings from Jakarta NoSQL.