Repository navigation
v4: Only permit integration through API methods exposed through nunit.engine.api #886
Description
We've faced various issues in v3 with it being unclear which public exposed methods are intended to be supported as interfaces. This leads to unexpected breaking changes for runners maintainers, and also lost time in trying to support interactivity with the engine through a range of unsupported methods.
For v4, I suggest we make only the methods in nunit.engine.api.dll publicly accessible. To do this, we would make methods internal in the other assemblies, and use InternalsVisibleTo to allow interaction between different assemblies.
Activity
CharliePoole commentedon Jan 30, 2021
Minor thing: I'd add "or any other API assemblies we decide we need."
CharliePoole commentedon Mar 7, 2022
We've made the basic decision: only API methods are guaranteed to remain stable. It remains to make current public methods internal or otherwise inaccessible to the greatest extent possible.
CharliePoole commentedon Feb 5, 2025
@nunit/engine-team
Excluding test and testdata assemblies, The following projects need to be reviewed and fixed as necessary. They are listed in top-down order, which is probably the easiest way to deal with them.
I also excluded the agent projects, since they are about to disappear, becoming separately maintained pluggable agent extensions. For that reason, anything needed by the agents from nunit.agent.core should remain public.
nunit.commonNo changes neededIf you have time to do one of these tasks, please edit to put your name or GitHub id on the same line, like this (@CharliePoole) or this (Charlie).
CharliePoole commentedon Oct 21, 2025
As one of the few remaining breaking changes planned for V4, this should be done in the next beta if at all possible.