Unit testing frameworks, naming, AAA, and test data setup in .NET

Overview

Unit testing in .NET is the practice of verifying small units of application behavior in isolation, usually by calling public methods or components directly and asserting the expected result. For a Fullstack .NET Developer, this commonly involves testing business services, validators, domain rules, MediatR handlers, mapping logic, API helpers, and other code that should be reliable without requiring a real database, network, file system, or browser.

The most common .NET unit testing frameworks are xUnit, NUnit, and MSTest. They all allow developers to write automated tests, run those tests from IDEs and CI pipelines, and express assertions about expected behavior. They differ mainly in their attribute names, lifecycle model, data-driven testing style, fixture support, and ecosystem preferences.

This topic matters because tests are not only a safety net. Good tests also document expected behavior, support refactoring, catch regressions, and encourage better software design. Poor tests can become slow, brittle, hard to read, and expensive to maintain. Interviewers often ask about unit testing because it reveals whether a developer understands code quality, maintainability, dependency boundaries, and production-readiness.

For interviews, you should be able to explain:

• The differences between xUnit, NUnit, and MSTest.
• The difference between a test framework and a test platform or runner.
• How to structure tests using Arrange-Act-Assert.
• How to write clear test names.
• How to set up test data without making tests fragile.
• How to choose between inline data, member data, builders, fixtures, fakes, mocks, and integration test setup.
• How to avoid common testing mistakes such as shared state, too much setup, testing implementation details, or writing tests with multiple unrelated assertions.

Core Concepts

Test Framework vs Test Platform

A common interview mistake is treating the test framework and test runner as the same thing.

A test framework defines how you write tests. It provides attributes, assertions, lifecycle hooks, and data-driven test features. Examples include:

• xUnit
• NUnit
• MSTest

A test platform or runner discovers and executes the tests. It integrates with tools such as Visual Studio Test Explorer, dotnet test, CI pipelines, and result reporting. In modern .NET, common test execution options include:

• VSTest: the long-established .NET test platform used by many existing projects and tools.
• Microsoft.Testing.Platform: a newer platform designed around modern .NET testing scenarios and executable-style test projects.

In practical terms, developers usually choose a test framework first, then configure the appropriate runner and packages so the tests can be discovered and executed locally and in CI.

dotnet test

A good interview answer should mention that framework choice affects test code style, while runner/platform choice affects execution, tooling, filtering, reporting, and CI behavior.

xUnit, NUnit, and MSTest at a Glance

The three frameworks solve the same core problem but use different conventions.

None of these frameworks is always the best choice. In interviews, the stronger answer is usually that a team should choose one framework consistently, understand its lifecycle rules, and write tests that are readable, isolated, deterministic, and easy to run.

xUnit Basics

xUnit is widely used in modern .NET projects. It intentionally avoids some traditional setup and teardown attributes. Instead, it encourages constructor-based setup and disposal-based cleanup.

A simple xUnit test:

using Xunit;

public class PriceCalculatorTests
{
    [Fact]
    public void CalculateDiscount_ValidCustomer_ReturnsDiscountedPrice()
    {
        // Arrange
        var calculator = new PriceCalculator();

        // Act
        var actual = calculator.CalculateDiscount(customerType: "Premium", price: 100m);

        // Assert
        Assert.Equal(90m, actual);
    }
}

A parameterized xUnit test:

using Xunit;

public class PriceCalculatorTests
{
    [Theory]
    [InlineData("Premium", 100, 90)]
    [InlineData("Standard", 100, 100)]
    public void CalculateDiscount_CustomerType_ReturnsExpectedPrice(
        string customerType,
        decimal price,
        decimal expected)
    {
        var calculator = new PriceCalculator();

        var actual = calculator.CalculateDiscount(customerType, price);

        Assert.Equal(expected, actual);
    }
}

Common xUnit concepts:

• [Fact]: a test with no external input data.
• [Theory]: a data-driven test that runs once for each input set.
• [InlineData]: simple inline test data.
• [MemberData]: data from a static property, field, or method.
• [ClassData]: data supplied by a separate class.
• Constructor: runs before each test method.
• IDisposable: cleanup after each test.
• IAsyncLifetime: async setup and cleanup.
• IClassFixture<T>: shared context for all tests in one class.
• ICollectionFixture<T>: shared context across multiple test classes.

xUnit is a good fit when a team prefers minimal attributes, constructor-based setup, and a modern .NET testing style.

NUnit Basics

NUnit is mature, flexible, and attribute-rich. Developers coming from other xUnit-style frameworks often find NUnit familiar because it has explicit setup, teardown, fixture, and test case attributes.

A simple NUnit test:

using NUnit.Framework;

[TestFixture]
public class PriceCalculatorTests
{
    [Test]
    public void CalculateDiscount_ValidCustomer_ReturnsDiscountedPrice()
    {
        // Arrange
        var calculator = new PriceCalculator();

        // Act
        var actual = calculator.CalculateDiscount("Premium", 100m);

        // Assert
        Assert.That(actual, Is.EqualTo(90m));
    }
}

A parameterized NUnit test:

using NUnit.Framework;

[TestFixture]
public class PriceCalculatorTests
{
    [TestCase("Premium", 100, 90)]
    [TestCase("Standard", 100, 100)]
    public void CalculateDiscount_CustomerType_ReturnsExpectedPrice(
        string customerType,
        decimal price,
        decimal expected)
    {
        var calculator = new PriceCalculator();

        var actual = calculator.CalculateDiscount(customerType, price);

        Assert.That(actual, Is.EqualTo(expected));
    }
}

Common NUnit concepts:

• [Test]: marks a test method.
• [TestCase]: supplies inline data to a parameterized test.
• [TestCaseSource]: supplies test cases from a method, property, or field.
• [SetUp]: runs before each test.
• [TearDown]: runs after each test.
• [OneTimeSetUp]: runs once before tests in a fixture.
• [OneTimeTearDown]: runs once after tests in a fixture.
• [Category]: groups tests for filtering.
• Assert.That(...): constraint-based assertion style.

NUnit is a good fit when a team wants a broad set of attributes, strong parameterized test support, and explicit lifecycle hooks.

MSTest Basics

MSTest is Microsoft’s test framework and is commonly seen in enterprise .NET projects, especially teams using Visual Studio and Microsoft tooling.

A simple MSTest test:

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class PriceCalculatorTests
{
    [TestMethod]
    public void CalculateDiscount_ValidCustomer_ReturnsDiscountedPrice()
    {
        // Arrange
        var calculator = new PriceCalculator();

        // Act
        var actual = calculator.CalculateDiscount("Premium", 100m);

        // Assert
        Assert.AreEqual(90m, actual);
    }
}

A parameterized MSTest test:

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]
public class PriceCalculatorTests
{
    [TestMethod]
    [DataRow("Premium", 100, 90)]
    [DataRow("Standard", 100, 100)]
    public void CalculateDiscount_CustomerType_ReturnsExpectedPrice(
        string customerType,
        int price,
        int expected)
    {
        var calculator = new PriceCalculator();

        var actual = calculator.CalculateDiscount(customerType, price);

        Assert.AreEqual(expected, actual);
    }
}

Common MSTest concepts:

• [TestClass]: marks a class containing tests.
• [TestMethod]: marks a test method.
• [DataRow]: supplies inline data.
• [DynamicData]: supplies data from a method, property, or field.
• [TestInitialize]: runs before each test.
• [TestCleanup]: runs after each test.
• [ClassInitialize]: runs once before tests in the class.
• [ClassCleanup]: runs once after tests in the class.
• [TestCategory]: groups tests for filtering.

MSTest is a good fit when the team wants Microsoft-supported conventions, Visual Studio integration, and straightforward test attributes.

Arrange-Act-Assert Pattern

Arrange-Act-Assert, often shortened to AAA, is a common structure for writing readable tests.

• Arrange: create the object under test, configure dependencies, and prepare input data.
• Act: execute the behavior being tested.
• Assert: verify the expected result or side effect.

Example:

[Fact]
public void CreateOrder_ValidInput_ReturnsOrderWithPendingStatus()
{
    // Arrange
    var customerId = Guid.NewGuid();
    var request = new CreateOrderRequest(customerId, totalAmount: 250m);
    var service = new OrderService();

    // Act
    var order = service.CreateOrder(request);

    // Assert
    Assert.Equal(OrderStatus.Pending, order.Status);
    Assert.Equal(customerId, order.CustomerId);
    Assert.Equal(250m, order.TotalAmount);
}

AAA matters because it makes the intent of the test obvious. The reader can quickly identify what is required, what behavior is executed, and what is expected.

A common mistake is mixing Act and Assert together:

// Less readable
Assert.Equal(250m, service.CreateOrder(request).TotalAmount);

This may be acceptable for very small tests, but in production codebases, a separate Act step usually improves debugging and readability.

One Act Per Test

A strong unit test usually has one meaningful Act step. This keeps the test focused and makes failures easier to understand.

Less focused:

[Fact]
public void OrderWorkflow_MultipleActions_Works()
{
    var service = new OrderService();

    var order = service.CreateOrder(100m);
    service.Approve(order.Id);
    service.Cancel(order.Id);

    Assert.Equal(OrderStatus.Cancelled, order.Status);
}

More focused:

[Fact]
public void Cancel_ApprovedOrder_ChangesStatusToCancelled()
{
    // Arrange
    var service = new OrderService();
    var order = service.CreateApprovedOrder(100m);

    // Act
    service.Cancel(order.Id);

    // Assert
    Assert.Equal(OrderStatus.Cancelled, order.Status);
}

There are exceptions, especially for integration tests or workflow tests, but for unit tests, one clear behavior per test is usually better.

Test Naming Standards

A test name should explain the behavior being verified. A common naming pattern is:

MethodName_Scenario_ExpectedBehavior

Examples:

CalculateDiscount_PremiumCustomer_ReturnsTenPercentDiscount
CreateOrder_TotalAmountIsZero_ThrowsValidationException
GetUser_UserDoesNotExist_ReturnsNull
Handle_ValidCommand_CreatesProduct

Good test names help developers understand failures without opening the test body. This is important in CI pipelines, where the test result may be the first clue.

Weak test names:

Test1
CreateOrderTest
ShouldWork
ValidCase

Better test names:

CreateOrder_ValidRequest_ReturnsPendingOrder
CreateOrder_MissingCustomerId_ThrowsValidationException
CreateOrder_TotalAmountIsNegative_ThrowsValidationException

Some teams prefer behavior-driven names:

Should_return_pending_order_when_request_is_valid
Should_throw_validation_exception_when_customer_id_is_missing

The exact convention matters less than consistency, clarity, and usefulness when a test fails.

What Makes a Good Unit Test

A good unit test should be:

• Fast: it should run quickly enough to execute often.
• Isolated: it should not depend on external state such as a real database, file system, network, or current time.
• Repeatable: it should produce the same result every run.
• Self-checking: it should automatically pass or fail without manual inspection.
• Focused: it should verify one behavior or one closely related behavior.
• Readable: future developers should understand the test quickly.
• Maintainable: the test should not break because of unrelated implementation changes.

These qualities are often more important than the specific framework chosen.

Unit Tests vs Integration Tests

Unit tests verify small units of behavior in isolation. Integration tests verify that multiple components work together, often involving real infrastructure or close substitutes.

A common interview point is that unit tests should not require a real SQL Server or external API. If a test needs real infrastructure, it may still be valuable, but it should usually be classified as an integration test.

Test Data Setup Strategies

Test data setup is the process of creating the inputs, entities, and dependency behavior needed for a test.

Good test data setup should be:

• Minimal: include only the values needed for the scenario.
• Clear: important values should be visible in the test.
• Reusable without hiding intent.
• Isolated from other tests.
• Easy to change when business rules change.

Common test data setup approaches include:

• Inline values for simple scenarios.
• Parameterized tests for multiple similar cases.
• Helper methods for repeated object creation.
• Test data builders for complex domain objects.
• Static data sources for larger parameterized cases.
• Fixtures for expensive shared setup.
• Fakes, stubs, or mocks for dependencies.

Inline Test Data

Inline data is useful when the input values are small and easy to understand.

[Theory]
[InlineData(0, false)]
[InlineData(1, true)]
[InlineData(10, true)]
public void IsPositive_Number_ReturnsExpectedResult(int value, bool expected)
{
    var actual = NumberRules.IsPositive(value);

    Assert.Equal(expected, actual);
}

Inline data is not ideal when the object graph is large, when values are hard to read, or when test data requires construction logic.

Member Data and Dynamic Data

When test data is too complex for inline attributes, use a method, property, or field that returns test cases.

Example with xUnit MemberData:

public class DiscountTests
{
    public static IEnumerable<object[]> DiscountCases =>
    [
        ["Premium", 100m, 90m],
        ["Employee", 100m, 80m],
        ["Standard", 100m, 100m]
    ];

    [Theory]
    [MemberData(nameof(DiscountCases))]
    public void CalculateDiscount_CustomerType_ReturnsExpectedPrice(
        string customerType,
        decimal price,
        decimal expected)
    {
        var calculator = new PriceCalculator();

        var actual = calculator.CalculateDiscount(customerType, price);

        Assert.Equal(expected, actual);
    }
}

This approach keeps the test method clean while still allowing richer data.

Test Data Builders

A test data builder is a helper object or method that creates valid default objects and allows each test to override only the relevant values.

Without a builder, tests can become noisy:

var customer = new Customer
{
    Id = Guid.NewGuid(),
    Name = "Test Customer",
    Email = "[email protected]",
    IsActive = true,
    CreatedAt = DateTimeOffset.UtcNow,
    Address = new Address
    {
        Street = "Main Street",
        City = "Test City",
        Country = "US"
    }
};

With a builder:

var customer = CustomerBuilder.Valid()
    .WithEmail("[email protected]")
    .AsActive()
    .Build();

Example builder:

public sealed class CustomerBuilder
{
    private Guid _id = Guid.NewGuid();
    private string _name = "Test Customer";
    private string _email = "[email protected]";
    private bool _isActive = true;

    public static CustomerBuilder Valid() => new();

    public CustomerBuilder WithEmail(string email)
    {
        _email = email;
        return this;
    }

    public CustomerBuilder AsInactive()
    {
        _isActive = false;
        return this;
    }

    public Customer Build()
    {
        return new Customer
        {
            Id = _id,
            Name = _name,
            Email = _email,
            IsActive = _isActive
        };
    }
}

Builders are useful when domain objects have many required fields. The trade-off is that builders can hide important setup if overused. The test should still make scenario-specific values obvious.

Object Mother Pattern

The Object Mother pattern uses factory methods to create common test objects.

public static class CustomerMother
{
    public static Customer ActiveCustomer()
    {
        return new Customer
        {
            Id = Guid.NewGuid(),
            Name = "Active Customer",
            Email = "[email protected]",
            IsActive = true
        };
    }

    public static Customer InactiveCustomer()
    {
        return new Customer
        {
            Id = Guid.NewGuid(),
            Name = "Inactive Customer",
            Email = "[email protected]",
            IsActive = false
        };
    }
}

This pattern is easy to start with, but it can grow into a large collection of similar methods. Builders are often more flexible for complex scenarios.

Fakes, Stubs, and Mocks

A test double replaces a real dependency in a test.

Common types:

• Fake: a working simplified implementation, such as an in-memory repository.
• Stub: returns controlled data to the system under test.
• Mock: verifies that a dependency was called in an expected way.

Example stub:

public sealed class StubExchangeRateProvider : IExchangeRateProvider
{
    public decimal GetRate(string fromCurrency, string toCurrency) => 1.2m;
}

Example test using the stub:

[Fact]
public void Convert_ValidAmount_UsesExchangeRate()
{
    // Arrange
    var provider = new StubExchangeRateProvider();
    var converter = new CurrencyConverter(provider);

    // Act
    var actual = converter.Convert(100m, "USD", "EUR");

    // Assert
    Assert.Equal(120m, actual);
}

Use mocks carefully. Verifying every method call can make tests tightly coupled to implementation details. Prefer asserting observable behavior unless interaction verification is the actual requirement.

Setup and Teardown

Setup and teardown are lifecycle mechanisms used to prepare and clean up test state.

Examples:

• xUnit: constructor and Dispose.
• NUnit: [SetUp] and [TearDown].
• MSTest: [TestInitialize] and [TestCleanup].

Setup methods can be helpful, but they can also hide important details. If every test uses a different setup, a shared setup method becomes confusing.

Less clear:

private OrderService _service = null!;
private Customer _customer = null!;

public OrderServiceTests()
{
    _customer = CustomerBuilder.Valid().Build();
    _service = new OrderService();
}

Clearer when setup is scenario-specific:

[Fact]
public void CreateOrder_InactiveCustomer_ThrowsValidationException()
{
    // Arrange
    var customer = CustomerBuilder.Valid().AsInactive().Build();
    var service = new OrderService();

    // Act
    Action act = () => service.CreateOrder(customer, totalAmount: 100m);

    // Assert
    Assert.Throws<ValidationException>(act);
}

Use shared setup only when it genuinely reduces duplication without hiding test intent.

Shared Fixtures

Fixtures are useful when setup is expensive, such as starting a test server, creating a database container, or initializing a shared resource.

Example xUnit class fixture:

public sealed class DatabaseFixture : IDisposable
{
    public string ConnectionString { get; }

    public DatabaseFixture()
    {
        ConnectionString = "Test database connection string";
        // Start database or initialize schema here.
    }

    public void Dispose()
    {
        // Cleanup resources here.
    }
}

public class ProductRepositoryTests : IClassFixture<DatabaseFixture>
{
    private readonly DatabaseFixture _fixture;

    public ProductRepositoryTests(DatabaseFixture fixture)
    {
        _fixture = fixture;
    }

    [Fact]
    public void GetById_ExistingProduct_ReturnsProduct()
    {
        // Use _fixture.ConnectionString
    }
}

Fixtures are common in integration testing. For unit tests, shared fixtures should be used cautiously because they can introduce shared mutable state and test order dependencies.

Testing Exceptions

Exception tests should verify the specific exception type and, when useful, meaningful details about the error.

xUnit example:

[Fact]
public void CreateOrder_NegativeAmount_ThrowsValidationException()
{
    var service = new OrderService();

    var exception = Assert.Throws<ValidationException>(() =>
        service.CreateOrder(totalAmount: -1m));

    Assert.Contains("amount", exception.Message, StringComparison.OrdinalIgnoreCase);
}

NUnit example:

[Test]
public void CreateOrder_NegativeAmount_ThrowsValidationException()
{
    var service = new OrderService();

    var exception = Assert.Throws<ValidationException>(() =>
        service.CreateOrder(totalAmount: -1m));

    Assert.That(exception!.Message, Does.Contain("amount"));
}

MSTest example:

[TestMethod]
public void CreateOrder_NegativeAmount_ThrowsValidationException()
{
    var service = new OrderService();

    Assert.ThrowsException<ValidationException>(() =>
        service.CreateOrder(totalAmount: -1m));
}

Avoid only checking that any exception was thrown. Specific assertions make tests more valuable.

Testing Async Code

Async tests should return Task and use await. Avoid .Result, .Wait(), or blocking calls because they can cause deadlocks, hide exceptions, and make tests less reliable.

[Fact]
public async Task Handle_ValidCommand_CreatesProduct()
{
    // Arrange
    var command = new CreateProductCommand("Keyboard", 50m);
    var handler = CreateHandler();

    // Act
    var result = await handler.Handle(command, CancellationToken.None);

    // Assert
    Assert.True(result.Success);
}

For cancellation behavior, pass a real CancellationToken and assert that the code observes it when cancellation is part of the contract.

Testing Private Methods

In most cases, private methods should be tested through public behavior. Private methods are implementation details. If a private method is complex enough that it feels difficult to test through the public API, it may indicate that the logic should be extracted into a separate class with its own public behavior.

Avoid this mindset:

I need to test every private helper directly.

Prefer this mindset:

I need to test the observable behavior that depends on that helper.

Avoiding Brittle Tests

A brittle test fails when implementation changes but behavior remains correct. Brittle tests slow teams down because developers stop trusting them.

Common causes of brittle tests:

• Testing private implementation details.
• Verifying too many mock interactions.
• Sharing mutable state between tests.
• Using real time, random values, or environment-specific data without control.
• Depending on test execution order.
• Using large object graphs where only one field matters.
• Asserting exact messages or formatting when the contract does not require it.

Better habits:

• Assert observable behavior.
• Keep setup minimal.
• Use deterministic test data.
• Inject time, randomness, and external dependencies.
• Make each test independent.
• Prefer builders or helper methods for complex setup.
• Keep unit tests separate from integration tests.

Test Categories and Filtering

Large projects often group tests by category, trait, or naming convention.

Examples:

// xUnit
[Trait("Category", "Unit")]
public class PriceCalculatorTests
{
}

// NUnit
[Category("Unit")]
public class PriceCalculatorTests
{
}

// MSTest
[TestCategory("Unit")]
public class PriceCalculatorTests
{
}

Test filtering is useful in CI:

dotnet test --filter Category=Unit

Depending on the framework and runner, filter property names can vary. The important interview point is that teams often separate fast unit tests from slower integration or end-to-end tests so pipelines can run the right test set at the right time.

Choosing Between xUnit, NUnit, and MSTest

A practical selection guide:

• Choose xUnit when the team wants a modern, minimal, convention-focused framework widely used in .NET open-source and ASP.NET Core examples.
• Choose NUnit when the team values rich attributes, flexible test cases, and explicit setup/teardown patterns.
• Choose MSTest when the team prefers Microsoft-supported conventions, Visual Studio familiarity, or existing enterprise standards.

In most interviews, the correct answer is not that one framework is universally superior. The better answer is that test quality depends more on isolation, naming, structure, data setup, and maintainability than on the framework itself.

Common Mistakes

Common mistakes include:

• Naming tests Test1, ShouldWork, or ValidCase.
• Testing multiple unrelated behaviors in one test.
• Using too much shared setup.
• Depending on test order.
• Using real external dependencies in unit tests.
• Mocking everything, including simple value objects or domain entities.
• Testing implementation details instead of behavior.
• Writing complicated logic inside the test itself.
• Using random values without making expected results deterministic.
• Ignoring async patterns and blocking on tasks.
• Treating code coverage percentage as proof of test quality.

Best Practices

Use these habits in real projects:

• Follow Arrange-Act-Assert.
• Use clear, behavior-focused names.
• Keep one meaningful Act step per test.
• Make tests independent and repeatable.
• Prefer simple setup inside the test when possible.
• Use builders for complex object creation.
• Use parameterized tests for repeated scenarios.
• Use mocks for behavior that must be verified, not for every dependency by default.
• Keep unit tests fast and infrastructure-free.
• Put integration tests in separate projects, folders, categories, or pipelines.
• Review tests like production code.
• Delete or refactor tests that no longer provide useful confidence.