Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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

Aperta
#996 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
45/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Ambito
documentation

Direzione di ricerca

Inizia individuando la documentazione di ITestBuilder e le fasi di discovery ed esecuzione dei test. Conferma dove inserire le indicazioni sui punti di estensione, quindi documenta il confine di marshalling tra processi e avvisa che i valori e le sottoscrizioni agli eventi creati durante la discovery potrebbero non fare riferimento agli stessi oggetti durante l’esecuzione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
Dockerfile
Stelle
601
Fork
158
Merge medio
15h 46m
PR unite (30g)
23

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di nunit/docs

Tutte le issue di nunit/docs

Issue simili

Altre issue su Documentation

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.