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

Document load-time vs execution-time constraints for test data sources and custom attributes

Aperta
  • Qualcosa non va?
#1,258 1 commento 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
40/100
Tipo di issue
Documentazione
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
csharp
Ambito
documentation, testing

Direzione di ricerca

Start by reading the discussions in #995 and #996 that this issue summarises, since the maintainers' comments set the scope. The work touches the Custom Attributes page, the TestCaseSource, ValueSource and FixtureSource pages, and the adapter docs on how often the assembly loads. Done means a shared 'Load time and execution time' section exists, the data-source and attribute pages link to it, and the worked example is included if it fits.

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

Descrizione

area:adapter area:framework

This issue is raised based on the discussions in PR #995 and corresponding issue #996, as raised by @craigfowler

  • Short summary

The actual problem: Data for a test (TestCaseSource, ValueSource, FixtureSource, and builders in general) is produced at load time and fixed before execution starts. Code that expects to share live state between the two phases fails quietly. Examples: subscribing to events while building test data, Random values, static side effects, changing data in SetUp.
The process boundary has nothing to do with it, since there might not even be one.

  • The problem

The symptom described in #996 is valid, two copies of the event bus, and the listener on one copy never saw events from the other.

  • The reason

"Two copies" suggests "one object copied across a boundary", so marshalling looks like the natural explanation. NUnit doesn't do that, though: argument values are never serialized from discovery to execution. The two copies come from the object being created twice. The code that builds it runs more than once, and each run makes a new instance.

  • Action

Based on the comments from @manfred-brands and @CharliePoole we need to update documentation on multiple attributes, and also keep a central place for the commonality.

Before raising a PR, please read all comments in #995 and #996.

  • Suggestions (used Claude to make this list, my former was too simple)
  1. A shared section, "Load time and execution time", which states:
    • The test tree, including every argument, is built at load time and cannot change during execution. Changing data in SetUp has no effect.
    • Arguments are not copied or marshalled. The test receives the objects created during the load it belongs to. This corrects the misconception behind #996.
    • Load-time code can run several times: once per method that uses a source, and once per assembly load. How many loads happen depends on the runner, so sources and builders must be repeatable, with no Random and no static side effects.
    • Anything that must be live during execution, such as event subscriptions, listeners or shared services, should be set up in OneTimeSetUp, SetUpFixture, SetUp or the test itself, not in a builder or data source.
  2. Custom Attributes page: extension-author rules, linked to the shared section:
    • Don't keep state on attribute instances. NUnit may create several instances of one attribute, and an attribute implementing both ITestBuilder and IApplyToTest can be two separate objects. This varies between NUnit versions.
    • Rework the "load time / execution time" grouping of interfaces on that page so it explains the consequences, not just the grouping, as Charlie suggested.
  3. Links from the data-source pages: TestCaseSource, ValueSource and FixtureSource each get a short "data must be repeatable" note linking to the shared section. Extend the existing TestCaseSource sentence, "no communication is possible between the load and execution phases…", rather than duplicating it.
  4. Adapter docs: how often the assembly is loaded under VS and dotnet test:
    • With RTD on, and with dotnet test: one load per execution run, and Explore and Run share the same loaded tests.
    • With RTD off: discovery loads the assembly in one testhost, and execution loads it again in a new testhost.
    • On .NET Framework: the framework runs in its own AppDomain inside the testhost, and only results and events cross back as XML.
    • Practical consequence: never expect state from discovery to still exist at execution.
  5. Optional, a worked example in the shared section: an object created in a data source, with a listener attached in a builder, which never sees events. Show why, then show the fix of attaching the listener in OneTimeSetUp. That is #996's own scenario, so it credits the report without repeating its explanation.
Lingua principale
Dockerfile
Stelle
601
Fork
158
Merge medio
1g 3h
PR unite (30g)
18

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.