Catalog
concept#Quality Assurance#Software Engineering#DevOps#Integration Testing

Dotnet Testing Framework

A categorization of testing frameworks, patterns and tools for .NET applications to ensure quality across unit, integration and end-to-end testing.

Dotnet Testing Framework refers to the landscape of testing libraries, patterns and tools used to validate .
Established
Medium

Classification

  • Medium
  • Technical
  • Technical
  • Intermediate

Technical context

GitHub Actions / GitLab CI / Azure PipelinesMocking frameworks (Moq, NSubstitute)Test databases and test containers

Principles & goals

Strictly separate unit tests from integration and E2E tests.Automate test execution in the CI/CD pipeline.Prefer deterministic tests and minimize external dependencies.
Build
Team, Domain

Use cases & scenarios

Compromises

  • Lack of test isolation leads to hard-to-reproduce failures.
  • Excessive reliance on mocks distorts integration behavior.
  • Insufficient test data management causes inconsistent results.
  • Write small, deterministic unit tests with clear assertions.
  • Categorize tests and prioritize fast feedback.
  • Use parameterized tests and test data management to reduce duplication.

I/O & resources

  • Source code and build artifacts
  • Test data and mocks
  • CI/CD infrastructure and runners
  • Test reports and metrics
  • Release blockers on failing tests
  • Improved regression detection

Description

Dotnet Testing Framework refers to the landscape of testing libraries, patterns and tools used to validate .NET applications across unit, integration and end-to-end levels. It covers framework choices, test architecture, automation in CI/CD and trade-offs such as speed versus isolation. It guides consistent test practices and maintainable test suites.

✔

  • Early detection of defects during development.
  • Increased regression safety for releases.
  • Clear metrics to measure test quality and coverage.

✖

  • Tests increase maintenance overhead and must be maintained.
  • Complete E2E coverage is time- and resource-intensive.
  • Flaky tests can undermine trust in the pipeline.

  • Code coverage

    Percentage of code covered by tests; indicator of test coverage but not a sole quality measure.

  • Test execution time

    Total duration of test execution, important for feedback cycles and CI performance.

  • Flakiness rate

    Proportion of intermittent failures in test runs, affects trust in the pipeline.

xUnit for a .NET Core project

A microservice uses xUnit for unit tests, combined with Moq for isolation and GitHub Actions for CI.

Integration tests with NUnit and TestServer

API integration tests use NUnit and ASP.NET Core TestServer to validate endpoints without production infrastructure.

End-to-end tests with Playwright and .NET

Browser-based end-to-end tests are integrated with Playwright, orchestrated in the CI pipeline for release qualification.

1

Select appropriate test frameworks based on project requirements

2

Set up test projects and standard templates

3

Integrate test execution into the CI/CD pipeline

⚠️ Technical debt & bottlenecks

  • Missing test coverage in critical paths
  • Outdated test framework versions in repo
  • Unstructured test data and manual test preparation
Slow test runsFlaky testsI/O-dependent integration tests
  • Relying solely on high coverage while tests are superficial.
  • Running expensive E2E tests on every commit instead of selective runs.
  • Complex integration tests without isolation and deterministic data.
  • Unclear test ownership between teams leads to duplicated tests.
  • Ignoring flaky tests instead of addressing root causes.
  • Gaming metrics to make quality indicators look better.
Experience with .NET test frameworks (xUnit, NUnit)Knowledge of test design and mockingCI/CD configuration and test orchestration
Fast feedback cycles for developersDeterministic tests to improve pipeline stabilityScalable test execution in CI/CD environments
  • • Limited CI resources for parallel tests
  • • Legacy code lacking testability
  • • Compliance requirements for test data