Unit Testing with xUnit

Unit testing verifies that a small, isolated piece of code — typically a single method or class — behaves correctly in response to a range of inputs, including edge cases and error conditions. xUnit.net is the de facto standard testing framework for modern .NET, favored over MSTest and NUnit by the .NET team itself (ASP.NET Core and the runtime use it internally). It embraces conventions that reduce boilerplate: no [TestClass] attribute is needed, test classes are just plain classes, and a fresh instance of the test class is created for every single test method, which naturally isolates test state without requiring manual setup/teardown resets.

xUnit distinguishes between two kinds of tests. A [Fact] is a test that is always true for a fixed scenario — it takes no parameters. A [Theory] is a parameterized test that should hold true for a set of data supplied via [InlineData], [MemberData], or [ClassData] attributes, letting you exercise the same assertion logic against many inputs without duplicating code. Assertions live on the static Assert class — Assert.Equal, Assert.True, Assert.Throws<T>, Assert.Null, and so on — and a failed assertion throws an exception that the test runner catches and reports, immediately halting that test method.

Because xUnit creates a new test class instance per test, a constructor is the natural place for per-test setup, and implementing IDisposable on the test class gives you per-test teardown. For expensive setup that should be shared *across* tests in a class — such as spinning up a database connection or an in-memory web host — use IClassFixture<T>, which xUnit instantiates once and injects into every test class constructor that requests it. For setup shared across multiple test classes, ICollectionFixture<T> combined with a [Collection] attribute achieves the same sharing at a broader scope, and also disables parallel execution between those classes so they don't race over the shared resource. A common mistake is asserting on floating-point equality with Assert.Equal(expected, actual) for double values, which can fail due to rounding error even when the values are 'logically' equal. Use the overload Assert.Equal(expected, actual, precision) or a tolerance-based comparison instead.

Real unit tests isolate the system under test from its collaborators. Libraries like Moq or NSubstitute let you create fake implementations of interfaces at test time, configure their return values, and verify that specific methods were called. Combined with dependency injection (constructor injection in particular), this makes classes trivially testable: pass a mock IEmailSender into a class that would otherwise send a real email, assert that Send was called with the expected arguments, and never touch a real mail server during the test run.