How would you structure an xUnit test class, and when would you use fixtures?

Structure xUnit tests and fixture lifetimes

Structures xUnit tests around per-test instances and shares only expensive infrastructure through deliberate class, collection, or assembly fixture lifetimes while preserving isolation and parallel safety.

1Say itAnswer out loud first

2CompareCompare with Core answer

3RefineRefine with Stronger and Advanced

TL;DR

xUnit creates a new test-class instance for each test, so constructor setup is naturally per test. I use a Fact for one case and a Theory when several inputs exercise the same rule. A class fixture shares an expensive resource within one class, while a collection fixture shares it across related classes. Ordinary mutable test data still belongs to each test.

Full answer below

Practice focus

Facts, theories, per-test instances, IAsyncLifetime, class fixtures, collection fixtures, and isolation.

Answer first

Answer path

Core answer first, then checkpoints toward a stronger answer.

Start
Core answer
Start here. This is the direct spoken answer to practice first.
Why this question matters
Fixture scope is an ownership decision. Broader sharing can reduce startup cost, but it also increases concurrency, cleanup, and isolation obligations; the shared object should usually be infrastructure, not a mutable business scenario.
xUnit creates a new test-class instance for each test, so constructor setup is naturally per test. I use a Fact for one case and a Theory when several inputs exercise the same rule. A class fixture shares an expensive resource within one class, while a collection fixture shares it across related classes. Ordinary mutable test data still belongs to each test.
Checkpoint
Stronger answer
Optional upgrade with examples, trade-offs, and sharper phrasing.
An integration-test collection might share one database container and application host because starting them per test is expensive. Each test still gets isolated data through a unique tenant, database, or deterministic reset boundary. The fixture owns infrastructure startup and disposal, not a mutable business record that tests update in sequence. I choose the narrowest fixture scope that gives useful reuse without creating order dependence.

Review signals

Use these to catch weak phrasing, shallow reasoning, and risky claims.

Common mistakesCandidateCommon mistakesMistakes that weaken the answer or signal shallow understanding.Open details

Details

Assuming the test-class instance is shared across methods.
Storing mutable scenario data in a collection or assembly fixture.
Depending on fixture creation order instead of composing ownership.
Disabling all parallel execution to hide test-data collisions.

How would you structure an xUnit test class, and when would you use fixtures?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Tech stacks

Skill areas

Was this drill useful?

Found this answer useful?

Human editorial direction

How would you structure an xUnit test class, and when would you use fixtures?

Practice focus

Answer path

Why this question matters

Review signals

Follow-up prompts

Continue practice

Tech stacks

Skill areas

Start a conversation

Was this drill useful?

Found this answer useful?

Human editorial direction