Skip to content

Provide mechanism for managing resources across engines and executions #4281

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 107 commits into from
Mar 31, 2025

Conversation

YongGoose
Copy link
Contributor

@YongGoose YongGoose commented Jan 27, 2025

Resolves #2816

Overview

  • Designing a class to manage context at the platform level
  • Adding a session-level store to LauncherSession
  • Adding a request-level store to Launcher
  • Exposing the request-level store in EngineDiscoveryRequest and TestPlan ExecutionRequest
  • Utilizing the request-level store in ExtensionContext
  • Tests for Jupiter, Suite engine, EngineTestKit etc.

I hereby agree to the terms of the JUnit Contributor License Agreement.


Definition of Done

@YongGoose
Copy link
Contributor Author

YongGoose commented Jan 27, 2025

What's the use case for this method? Test engines don't have access to the Launcher so we'll need to pass this store as part of LauncherDiscoveryRequest and ExecutionRequest, don't we?

I’ve drafted an initial version 02ef45b , but I think there’s still a lot of room for improvement.
If you could point out any mistakes I’ve made, I’ll make sure to fix them right away.

Even though I’ve been studying, I find it quite challenging.

PS. While resolving a git conflict, I accidentally included the commit history from the main branch, So i create a new PR 😁

@YongGoose
Copy link
Contributor Author

@marcphilipp

I think you must be very busy with the release of version 5.12 M1.
Please feel free to leave your comments whenever it’s convenient for you.

@YongGoose
Copy link
Contributor Author

YongGoose commented Feb 6, 2025

@marcphilipp

This PR is something I’ve personally been eager to work on for a long time.
However, I still don’t have a clear sense of how to proceed with it.

If this feature gets added to JUnit 5, it would be a huge learning opportunity for me and a great addition to my skill set.
That said, I don’t want to cause any fatigue for the JUnit team—especially you, Marc.

So if you feel that I’m not quite ready to take on this PR yet, please let me know, and I’ll close it.
Either way, I’ll keep looking for other issues and do my best to contribute! 🙂

I think I sounded a bit too weak.
After completing the other PR, I will make sure to implement this perfectly, no matter what.

But if you’re willing to let me see it through, I’ll do my best as always.
I’ll likely need more guidance than usual compared to other tasks.

@YongGoose YongGoose force-pushed the feature/2816 branch 3 times, most recently from c9d5ac0 to 7d98e9a Compare February 13, 2025 10:48
Copy link
Contributor Author

@YongGoose YongGoose left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removing the store from the discovery process sounds like a good idea.
As the next step, I will proceed with the following task.

  • Tests for Jupiter, Suite engine, EngineTestKit etc.

Thank you, Marc!

@YongGoose
Copy link
Contributor Author

@marcphilipp

While working on the tests, I have a question.

As per your guidance, I am adding tests for JupiterEngine, SuiteEngine, and EngineKit. However, I am wondering if SuiteEngine requires furthermore testing.

Since the main focus of this PR is adding request-level and session-level stores, I am designing the tests around that.

The execute method in SuiteEngine utilizes the requestLevelStore from ExecutionRequest to run multiple tests. In my view, the core role of execute is to execute multiple tests, and this functionality is already being validated by existing tests.

Do you think any additional tests are needed for SuiteEngine?

PS. I truly appreciate how you not only explain things but also implement the code to make communication more efficient—it’s been incredibly helpful. 👍🏻
However, this time, I’d like to try implementing it on my own! 🙂

@marcphilipp
Copy link
Member

The execute method in SuiteEngine utilizes the requestLevelStore from ExecutionRequest to run multiple tests. In my view, the core role of execute is to execute multiple tests, and this functionality is already being validated by existing tests.

Do you think any additional tests are needed for SuiteEngine?

I was thinking about a very basic tests that verifies that SuiteEngine passes along the requestLevelStore to test engines. It's probably sufficient to mock SuiteLauncher and check that a non-null store is passed to it.

@marcphilipp
Copy link
Member

@YongGoose I'll discuss this PR with the team on Friday and will leave it open until then.

@marcphilipp marcphilipp marked this pull request as ready for review March 25, 2025 15:21
@marcphilipp marcphilipp self-requested a review March 25, 2025 15:21
Copy link
Contributor Author

@YongGoose YongGoose left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Documentation work is always challenging. 🤯 I’ve added comments where I felt additional explanation or improvements might be helpful.

Thank you, as always, for taking the time to provide feedback on my work! 🙇🏻

@YongGoose
Copy link
Contributor Author

@marcphilipp
I reviewed the changes 677648a, and I think limiting the scope to define the range is a great approach. 👍🏻

In the previous method, we had to add new methods every time we wanted to extend functionality, which was a drawback. However, with these changes, the flexibility for expansion has significantly improved.

Would it be okay to ask if there were any further discussions about this PR during the team meeting?

@marcphilipp
Copy link
Member

@mpkorstanje @leonard84 Is this something that can be adopted in the Cucumber/Spock engines?

@marcphilipp marcphilipp merged commit 468ce37 into junit-team:main Mar 31, 2025
13 checks passed
@marcphilipp
Copy link
Member

@YongGoose Thank you for all your hard work! 👍 🙇

@YongGoose
Copy link
Contributor Author

Thank you for all your hard work! 👍 🙇

This project was personally very challenging for me. In the beginning, there were moments when I considered giving up, but instead of wasting time on such thoughts, I decided to put in even more effort and give it my all.

As I kept pushing forward, two months flew by, and I was finally able to complete the task.
Thank you so much @marcphilipp. I truly believe that I could never have accomplished this without your help. 🙇🏻‍♂️

I will do my best in the next task as well, just as I did with this one. 💪🏻
I am always grateful to you.

@marcphilipp
Copy link
Member

Would it be okay to ask if there were any further discussions about this PR during the team meeting?

Sure! We took a few steps back and discussed whether we need this at all. In the end, we decided we do since it "resource management" was the reason for introducing LauncherSession{Listener} in the first place and this mechanism provides a proper way of interacting with such resources in tests without having to use static variables or system properties.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Provide mechanism for managing resources across engines and executions
2 participants