rmannibucau commented on pull request #14272:
URL: https://github.com/apache/beam/pull/14272#issuecomment-813524094
> Judging by any data I can find, JUnit4 is still by far the dominant
version in use. Why? JUnit5 isn't so much an upgrade but just a totally
different project with a shared name and some similar concepts, and also with
API/functionality regressions that are not a priority for JUnit team. The
migration cost for a large organization is huge, as much as migrating to an
unrelated test framework, and benefits not enough to justify the investment. It
reminds me of Python 2 to 3.
Using CI data yes because it exists but using new project stacks not really
because projects start on up to date framework and junit4 said they will not
upgrade the framework (until a CVE pops up) so Junit4 can be seen as dead as of
today and JUnit5 the main alternative. I know it is hard to have the difference
in terms of data but people doing service on new projects will surely confirm
what i saw over the last year.
In terms of cost, it is generally cheap to have done it on big suites, the
only cost is about migrating rules to extensions and it is not that costly in
practise and rest is mainly a sed so not as bad as python even if it can look
like that upfront.
Last point is that with junit 5.7, junit5 caught back its lateness on junit4
(mainly rules which were enabling more before) so guess it is time for beam to
move anyway. It can't go back anyway :).
> We export our "Beam Model Compliance" test suite via JUnit4 category. So
it is a critical breaking change to do that differently.
JUnit 5 has groups and it does not have to break, guess junit4 should stay
in a beam-junit4 module and jupiter move to a beam-junit5 one. Current
beam-core ("put it all") will become a kind of bom (with an empty jar to not
break deps too much?) and core can move in a beam-core-engine, no breaking
change for anyone if desired.
To have done the work, there is no real reason to be that coupled with a
testing framework - don't get me wrong, it was natural in a first version of
the framework, I'm not blaming - so I guess it is mainly about abstracting the
few basic primitives (primitives not the whole hamcrest stuff ;)).
Side note: it can be an opportunity to split beam internal harnessing and
user testing API. Using direct runner enable to cover user case quite well and
does not need the test pipeline or so which mainly brings constraints and as
much off toggle than feature so rethinking the API and maybe splitting both
makes sense to me.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
