Extensibility docs should signpost & warn where developers could be caught out by cross-process marshalling
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
Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di nunit/docs
-
type:newpage
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
I maintainer di solito rispondono entro 1 giorno
-
area:framework
Difficoltà 4/5 3-5 giorni Idoneità per principianti 40/100
nunit/docs#1151 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Document F# EqualToApertaarea:framework
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
I maintainer di solito rispondono entro 1 giorno
-
area:framework
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
nunit/docs#1045 · 6 commenti ·
I maintainer di solito rispondono entro 1 giorno
Issue simili
-
bug documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
ClickHouse/clickhouse-cs#638 ·
I maintainer di solito rispondono entro 1 giorno
-
Création-JDV
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
-
documentation
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 92/100
githubnext/gh-aw-workshop#4046 ·
I maintainer di solito rispondono entro 1 giorno
-
specification
Difficoltà 1/5 1-3 ore Idoneità per principianti 78/100
WICG/webmonetization#751 ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 78/100
stratum-mining/sv2-ui#294 ·
I maintainer di solito rispondono entro 7 giorni