Introduce @DependsOn to prioritize test method execution order

[duckladydinh]

@Update: Now it works exactly like TestNG, which means if A depends on B, and B is disabled, then A is disabled as well.

Hi everyone,

I am creating a pull request for this feature. It should work similar to TestNG (@Test(dependsOn = ...)) but it will not disable the test if some test fails. It just gives methods a priority like @Order.

It would be great if someone can give me some advice how to improve it.

Thank you :)

[sbrannen]

Tentatively slated for 5.5 M1 for the purpose of team discussion.

[sbrannen]

Hi @duckladydinh,

Thanks for opening the issue and submitting the PR!

I am creating a pull request for this feature. It should work similar to TestNG (@Test(dependsOn = ...)) but it will not disable the test if some test fails. It just gives methods a priority like @Order.

Although I think there is merit in mere "dependent ordering" as in the PR, I think it would be worth investigating the possibility for "not executing" methods if a method that they depend on fails.

For example, if C depends on A and A fails, then C should be aborted. That's basically what TestNG does, and I think it might be possible to implement this elegantly in JUnit Jupiter by implementing the TestWatcher API introduced in JUnit Jupiter 5.4. Of course, I have not tried to implement it myself, so I'm just thinking out loud here.

[duckladydinh]

Hi @sbrannen , thank you for the suggestion. I think I have something done already based on your suggestion. My design is to keep the DependsOnAnnotation as it is, and add a separate TestWatcher :).

[thespags]

Hi is there any update on when this PR might be merged in. There hasn't been any follow up since end of last year. Thank you.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. Thank you for your contribution.

[spags-twilio]

Hi. I wanted to check in if there is any update or concerns? This is one of the features available in TestNG that I miss when working in JUnit5. It helps isolate problems in tests when you have good dependency management.

[fogrid]

Also checking about this, this feature would be very usable, is it going to be merged?

[ahoehma]

Any news here?

[sbrannen]

@ahoehma, this issue still has the waiting-for-interest label.

[jzhang-SD]

This feature would be very useful

[thespags]

I am still interested.

[ericparton]

I'm not sure what happened here, but this would be a useful feature to have. It's something that TestNG can do, and the lack of support makes migrating from TestNG to JUnit difficult.

[armlesshobo]

I'm also interested in this.

[Mercuron]

I'm also interesting in this. I have a lot of tests that I want to run in the order in which they are written (yes this is the case). When there are few of them, there is no problem.

@Test
@Order(10)...

@Test
@Order(11)...

But when the dough gets too much (100-200 consecutive tests) and I need to change/insert something in the middle, it's a big pain.

[YongGoose]

@marcphilipp @sbrannen

After completing the following task, I’m interested in this one.

• Provide mechanism for managing resources across engines and executions #4281

Could you let me know if there are any updates? 🤔

[sbrannen]

Could you let me know if there are any updates? 🤔

No, there are currently no updates on this proposal.

However, we will discuss it within the team.

[sbrannen]

As a side note, this is related to:

• Introduce first-class support for scenario tests #48

[YongGoose]

Could you let me know if there are any updates? 🤔

No, there are currently no updates on this proposal.

However, we will discuss it within the team.

Thank you for your response!

I think it would be good to apply the status: team discussion label.
Once the discussion is over, I’d appreciate it if you could share the outcome. 🙇🏻

[marcphilipp]

Quick update: We briefly discussed this during the last team call. It has implications on test discovery (when selecting a method with a @DependsOn annotation, its dependencies also need to be added to the test plan), ordering, parallel execution, and execution (optionally skipping a test when a test it depended on failed). Due to this complexity we don't think now's the right time to tackle it given the timeline for 6.0. It's not spec'ed out enough that we'd feel comfortable to put it "up-for-grabs", either. Therefore it's currently on hold pending more research from a core team member.

[YongGoose]

Quick update: We briefly discussed this during the last team call. It has implications on test discovery (when selecting a method with a @DependsOn annotation, its dependencies also need to be added to the test plan), ordering, parallel execution, and execution (optionally skipping a test when a test it depended on failed). Due to this complexity we don't think now's the right time to tackle it given the timeline for 6.0. It's not spec'ed out enough that we'd feel comfortable to put it "up-for-grabs", either. Therefore it's currently on hold pending more research from a core team member.

Thanks for the update! 👍🏻
If you need any help with the additional research, feel free to reach out!!