[SeanKilleen]

Closes #1293

What changed

setupfixture.md gains two sections:

• Inheritance. [SetUpFixture] is inherited; the concrete class's namespace sets the scope; an abstract base is not a setup fixture by itself; and fixture attributes are resolved one inheritance level at a time, so [TestFixture] on the derived class wins over the inherited [SetUpFixture], while a derived class with only [Test] methods becomes a setup fixture and its tests are not discovered. Ends with the tip to put [SetUpFixture] on the concrete class anyway.
• Sharing setup across projects. The agreed pattern from the discussions: a plain class in the shared package plus a tiny [SetUpFixture] in each consuming test project, and the static Lazy<T> alternative for when consumers cannot be asked to add a class.

onetimesetup.md and setup-and-teardown.md get a one-line cross-link each to the new sections.

Executable snippets

Every example on the page is a region in SetUpFixtureAttributeExamples.cs and runs as part of the snippets test suite. The file also contains SetUpFixtureInheritanceVerification, which builds this assembly's test tree with DefaultTestAssemblyBuilder (the same path the framework uses at discovery) and asserts:

• the abstract base class does not appear in the tree
• the concrete derived class is built as a SetUpFixture under its own namespace and contains the consumer tests
• the derived class marked [TestFixture] is built as a TestFixture with one test
• the derived class with only a [Test] method is built as a SetUpFixture and the test is absent

This confirms the third rule from the issue, which @OsirisTerje had flagged as "need to check it". The undiscovered test asserts Assert.Fail, so it would also break the suite if NUnit ever started discovering it. dotnet test --list-tests likewise does not list it. The rules match the GetFixtureBuilderAttributes loop in DefaultSuiteBuilder, which walks the inheritance chain one level at a time and stops at the first level with any fixture attribute.

Verification

• dotnet test docs/snippets/Snippets.slnx: 608 passed, 0 failed (NUnit), 2 passed (NUnitLite)
• markdownlint and cspell: 0 issues on the changed files
• docfx docs/docfx.json builds; all six snippet references and the three anchor cross-links render

🤖 Generated with Claude Code

[github-actions]

📖 Docs preview removed because this PR was closed.

[Copilot]

🟡 Changes recommended

The article and published snippet incorrectly promise per-run initialization for a static Lazy<T>, which follows the loaded type's lifetime instead.

1 open issue

• Clarify Lazy<T> lifetime and teardown behavior · New

What changed in this PR

Addresses #1293 by documenting SetUpFixture inheritance and patterns for sharing setup logic across test projects.

Changes:

• Explains inherited namespace scope and fixture-attribute precedence.
• Adds shared-package and static Lazy<T> examples.
• Adds discovery-verification tests and cross-links from related setup documentation.

File	Description
docs/​snippets/​Snippets.NUnit/​Attributes/​SetUpFixtureAttributeExamples.cs	Adds inheritance and sharing examples, plus discovery-verification tests.
docs/​articles/​nunit/​writing-tests/​setup-and-teardown.md	Links to the inheritance and shared-setup guidance.
docs/​articles/​nunit/​writing-tests/​attributes/​setupfixture.md	Documents inheritance rules and cross-project setup patterns.
docs/​articles/​nunit/​writing-tests/​attributes/​onetimesetup.md	Links to the shared-package setup pattern.

_{Review effort: Balanced}

[OsirisTerje]

Very good to have this described. We talk about typical patterns for usage. This is one of them. Hope we can reach more of these.