Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Extensibility docs should signpost & warn where developers could be caught out by cross-process marshalling

Open
  • Is something wrong?
#996 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
3/5
Estimated time
1-2 days
Newbie friendliness
45/100
Issue type
Documentation
Clarity
Mostly clear
Activity status
Stale
Domain
documentation

Research direction

Start by locating the documentation for ITestBuilder and the discovery and test execution phases. Confirm where extension-point guidance belongs, then document the cross-process marshalling boundary and warn that values and event subscriptions created during discovery may not refer to the same objects during execution.

Written by the indexing model from the issue text.

Description

This relates to something that I have had this explained to me somewhere before, but it was years ago and I can't find where that discussion happened. I've looked through SO questions and issues/discussions on the NUnit repo.

There is a limitation, really a feature/consequence of NUnit's design (and not one I consider to be bad) In the default usage the "discovery and test suite/case creation" phase occurs at arms length to the "test execution" phase, I believe in a separate .NET process. From what I recall of the last time this was explained to me, objects/values which are created during discovery/creation are then marshalled in some manner over to the execution. Examples of this are where test case parameter values are injected by something which implements ITestBuilder.

When those objects turn up in the test case as a method parameters, they are not actually the precise same objects as were created in the test builder, because they have crossed a boundary (again, I think that's a process boundary). This can have some unexpected and baffling consequences to a developer if they had not had this boundary-crossing pointed out to them. For example, an object which emits events passed as a test case parameter. If an event listener is subscribed to that object over in the "discovery & creation" part of the test suite then events which are emitted during the test (triggered by logic that executes within the test) won't be observed by the subscriber. That's because the object emitting the events isn't actually the precise same object that was subscribed-to. The object emitting the events is a marshalled-copy of the original object.

I think the docs should point this out for extension points which can lead to this behaviour. It's not obvious if you are not already familiar with the deep internals of NUnit. Even having already been told once, over the course of a few years I managed to forget and was caught out by this a second time.

Dominant language
Dockerfile
Stars
601
Forks
158
Avg merge
1d 1h
Merged PRs (30d)
19

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nunit/docs

All issues in nunit/docs

Similar issues

More Documentation issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.