Skip to content
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.

Sign up for GitHub

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

Jump to bottom

Isolate agents from the engine itself #1578

Open
CharliePoole opened this issue Dec 29, 2024 · 5 comments
Open

Isolate agents from the engine itself #1578

CharliePoole opened this issue Dec 29, 2024 · 5 comments
Assignees
@CharliePoole
Labels
Blocked Feature
Milestone
4.0.0-beta.1

Comments

@CharliePoole
Copy link
Member

This is a long-standing direction for V4, but one for which no actual issue had previously been written. This issue aims to capture the overall goal and steps needed beyond what has been done to date.

Isolation of the various agents that run tests from the engine itself is an important feature because it allows the two sides to evolve separately. Perhaps more important, it will allow the agents to stop evolving when the runtimes they support reach EOL, while still allowing users to continue to use those agents if they need to.

Currently, agents do not reference the engine but they do reference engine.core, which is also referenced by the engine itself. We aim to eliminate nunit.engine.core. Types referenced by the engine will move into nunit.engine while those referenced by agents will move into a new assembly, nunit.agent.core. FWIW, I managed to do this with the TestCentric engine, only needing to duplicate a few types in the two surviving assemblies.

This issue has a soft dependency on #1049. It will be more convenient to first remove ExtensionManager and related classes from nunit.engine.core rather than moving those types twice.

Issue #909 has a similar soft dependency on this one.

issue #1539 is also related in that I would expect to create the new nunit.agent.core assembly as nullable in the first place.
@CharliePoole CharliePoole self-assigned this Dec 29, 2024
@CharliePoole CharliePoole added this to the 4.0.0-beta.1 milestone Dec 29, 2024
@CharliePoole CharliePoole mentioned this issue Dec 29, 2024
Closed
@CharliePoole
Copy link
Member Author

CharliePoole commented Dec 29, 2024 •
edited
Loading

UPDATE - Replacing earlier plan

  • Remove all Types from nunit.engine.core that are no longer used. Only a few of these exist.
  • Move Types (mostly interfaces) shared by both the engine and the agents to the api assembly.
  • Move Types used only by the engine to the engine.
  • Move shared implementation Types to a new NUnit.Common assembly.
  • Rename the nunit.engine.core assembly to nunit.agent.core.

@CharliePoole
Copy link
Member Author

@manfred-brands since this issue moves Types from one project to another, it's likely to make merging difficult for one or both of us. Of course, we can deal with a messy merge but I'm open to suggestions for making it easier.

FTI, there are already a few other PRs, which have been merged so you may want to rebase before dealing with this one.

@manfred-brands
Copy link
Member

@manfred-brands since this issue moves Types from one project to another, it's likely to make merging difficult for one or both of us. Of course, we can deal with a messy merge but I'm open to suggestions for making it easier.

FTI, there are already a few other PRs, which have been merged so you may want to rebase before dealing with this one.

I suggest for me to finish the NUnitEngine directory today. We can then merge #1580 then you can safely move classes between the to engine assemblies. I can create a new PR for the Console.

@CharliePoole
Copy link
Member Author

That's a good idea. And if you can't finish today, I'll wait and then rebase locally. I think all the files I have not moved will be dealt with correctly, and I can re-apply your changes for the ones that I moved pretty easily.

@CharliePoole CharliePoole mentioned this issue Jan 2, 2025
Merged
@CharliePoole
Copy link
Member Author

Some cleanup of the existing code is needed before continuing with this issue. Marking as blocked.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@CharliePoole CharliePoole

Labels
Blocked Feature
Projects
None yet
Milestone
4.0.0-beta.1
Development

No branches or pull requests
2 participants
@CharliePoole @manfred-brands