dotnet-netarchtest

Write architecture rules as .NET unit tests using the NetArchTest.Rules fluent API.

Updated Mar 31, 2026
One-click install
npx skills add https://github.com/zhenpengLai/myuseskill --skill dotnet-netarchtest-zhenpenglai
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: dotnet-netarchtest
Source: https://github.com/zhenpengLai/myuseskill/tree/main/dotnet-netarchtest
Command: npx skills add https://github.com/zhenpengLai/myuseskill --skill dotnet-netarchtest-zhenpenglai

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill requires NetArchTest.Rules, and includes references (resource) components.

What problem does it solve? Architecture boundaries in .NET projects often erode silently as code evolves, with no automated way to catch forbidden dependencies or layering violations. This Skill encodes durable architecture rules as executable unit tests so dependency drift fails the build instead of slipping into production. ## Core Features & Use Cases - Fluent Architecture Assertions: Use NetArchTest.Rules to assert namespace layering, forbidden dependencies, naming conventions, and type shape rules (sealed, public, interface implementation). - Bootstrap Support: Detects missing NetArchTest.Rules setup, adds the NuGet package, creates a first boundary test, and wires architecture tests into the standard test command and CI. - Ready-Made Rule Patterns: Reference guides cover Clean Architecture, layered/N-tier, CQRS, DDD, controller conventions, and circular dependency detection via namespace slices. - Use Case: A team wants to block the UI layer from referencing the data layer directly. The Skill adds a NetArchTest rule asserting that types in the Presentation namespace have no dependency on the Data namespace, failing the test suite on violation. ## Quick Start Ask the agent to add NetArchTest architecture tests that prevent the UI layer from referencing the data layer in this .NET solution.

Frequently Asked Questions about dotnet-netarchtest

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I write architecture tests in .NET with NetArchTest?▼

Add the NetArchTest.Rules NuGet package to your test project, then use the fluent API: select types with Types.InAssembly, filter with That() predicates like ResideInNamespace, and assert with Should() or ShouldNot() conditions such as HaveDependencyOn. Call GetResult() and assert IsSuccessful in your test framework.

How do I enforce layer dependencies in Clean Architecture tests?▼

Write a rule asserting that types in your Domain assembly do not have dependencies on Application, Infrastructure, or Web namespaces using ShouldNot().HaveDependencyOnAny(). NetArchTest fails the test when any domain type references a forbidden layer, catching drift in the normal test run.

Does NetArchTest work with xUnit, NUnit, and MSTest?▼

Yes, NetArchTest.Rules works with any .NET unit-test framework because it returns a plain TestResult object. You assert on result.IsSuccessful using whatever assertion library your test project already uses, and it runs as part of the standard dotnet test command.

NetArchTest vs ArchUnitNET for .NET architecture testing?▼

NetArchTest.Rules is a lightweight, free, open-source library suited to fluent assertions on namespaces, dependencies, and layering. When a project needs richer architecture modeling and a heavier DSL than NetArchTest comfortably provides, ArchUnitNET is the more appropriate choice.

How do I detect circular dependencies between namespaces in .NET?▼

Use NetArchTest's slice pattern: call Types.InAssembly(assembly).Slice().ByNamespacePrefix("MyApp") and then assert slices.Should().NotHaveDependenciesBetweenSlices(). The test fails when namespace slices reference each other cyclically.

When should I not use NetArchTest for architecture rules?▼

Avoid NetArchTest when the project requires rich architecture modeling, complex custom assertions, or a heavier DSL beyond its fluent API scope. It is designed for durable, readable boundary rules like forbidden dependencies and layering, not exhaustive architectural analysis.