search

junit-team / junit5

✅ The 5th major version of the programmer-friendly testing framework for Java and the JVM
https://junit.org
Eclipse Public License 2.0
6.43k stars 1.49k forks source link

Change visibility of junit-vintage to get other test engines running #445

Closed aaschmid closed 8 years ago

aaschmid commented 8 years ago

Hi junit-team,

I am the maintainer of https://github.com/TNG/junit-dataprovider and in order to be able to migrate to the new JUnit5 engine for new test cases in the future I would like to provide a test engine for it. This would make it possible to migrate step by step.

To achieve that I created the following:

Now here are my questions:

  1. Are you OK with extending your (internal) APIs like that or is there an easier way which I completely overlooked? (Even if could think about better solutions to achieve what I need but this can be discussed after you do not see another solution and would be OK with extending visibility ...)
  2. As I used @Test and @UseDataProvider for annotating my test cases, obviously the junit-vintage engine also tries to execute the test cases and fails with the error "java.lang.Exception: Method testAdd should have no parameters ..." due to "BlockJUnit4ClassRunner" and its validations. Can you think of a solution or do I have to create a custom runner too? (Please note that this would require even more classes and methods to be visible but it would work as I have already tested it :-) If you want to see the code to compare or so, just let me now).

I appreciate every help and your great work so far.

Thanks, Andreas

aaschmid commented 8 years ago

Of course one could always start a new class for "junit-jupiter" test cases but I like the idea to even mix it up and therefore migrate smoothly :-)

And also depending on your @DynamicTest feature set, I want to provide the "junit-dataprovider" as "junit-jupiter" extension or not ... (I could also think about migrating the worth features to your code ;-) )

marcphilipp commented 8 years ago

Hmm, we're certainly not comfortable with you extending our internal APIs because we might need to change them in the future...

We still have parameterized tests on our agenda (see #17). When we get to implementing it, we will certainly provide an Jupiter extension point for it so you don't have to write a new engine to provide a new way to supply data. However, we're not there, yet.

aaschmid commented 8 years ago

Hi @marcphilipp,

hm ... I am ok with code changes in the future if I use an internal API. Also I understand that you want to define the API. Does that mean I just have to wait for the above mentioned Jupiter extension point?

If yes, can you tell me more about your plans / concepts / integrations for parameterized tests such that I can implement / help implementing it and getting it sooner?

Cheers, Andreas

aaschmid commented 8 years ago

I now created my own test engine. It's currently in an alpha state, see https://github.com/TNG/junit-dataprovider/tree/issue75-second-try. Filtering is not implemented and it is build from scratch. A lot of code is quite similar to junit-vintage.

So I don't mind if you want to close this issue :-)

sbrannen commented 8 years ago

Thanks for the feedback.

Closing this issue.