MNW #036: Enforcing Software Architecture With Architecture Tests

Read time: 5 minutes

A big thank you to our sponsors who keep this newsletter free to the reader:

Today's issue is sponsored by Hasura, an open-source engine that gives instant GraphQL and REST APIs on new or existing SQL Server, enabling teams to ship apps faster.

And by Rebus Pro. Rebus is a free .NET "service bus", and Rebus Pro is the perfect one-up for serious Rebus users. Use Fleet Manager to get Slack alerts when something fails and retry dead-lettered messages with a click of the mouse.

Software architecture is a blueprint for how you should structure your system. You can follow this blueprint strictly, or you can give yourself varying levels of freedom.

But when deadlines are tight, and you start cutting corners, that beautiful software architecture you built crumbles like a house of cards.

How can you enforce your software architecture?

By writing architecture tests.

Architecture tests are automated tests that verify the structure and design of your code.

You can use them to enforce your software architecture and the direction of dependencies of your projects.

In this week's issue I'll explain how to:

Write architecture tests
Enforce architecture
Enforce design rules

Let's dive in.

Writing Architecture Tests

You write architecture tests the same as any unit test in your application. There's an excellent library for writing architecture tests that already implements the boilerplate code we need to start writing tests.

We're going to use the NetArchTest.Rules library for writing architecture tests.

First, you have to install the NuGet package:

And now you can use it to write rules in your test project.

The starting point for writing architecture tests is the static Types class, which you can use to load a set of types.

Once you have loaded your types you can further filter them to find a more specific set of types.

Some of the available filtering methods:

ResideInNamespace
AreClasses
AreInterfaces
HaveNameStartingWith
HaveNameEndingWith

Finally, when you are satisfied with your selection, you can write the rule you want to enforce by calling Should or ShouldNot and applying the condition you want to check.

Here's an example checking that all classes in the domain assembly are sealed:

Enforcing Architecture Rules

Architecture tests are particularly useful to enforce software architecture rules in a layered architecture or Modular Monolith.

Let's take the example of the Clean architecture:

Domain should not have any dependencies
Application should not depend on Infrastructure
Infrastructure should depend on Application and Domain

Here's how you can write tests for enforcing architecture rules.

Domain should not have any dependencies

Application should not depend on Infrastructure

Infrastructure should depend on Application and Domain

How the NetArchTest.Rules library works is by scanning the imported namespaces of your types.

Because of this, writing negative conditions like in the previous two examples is straightforward.

But writing positive conditions has to be scoped to a more specific set of types.

For example, we can validate this dependency by checking that all repositories must have a dependency on the Domain namespace.

Enforcing Design Rules

Another valuable use case for architecture tests is enforcing design rules in your application.

Design rules are more specific than project references, and focus on the implementation details of your classes.

Here are some design rules that you can enforce:

Services must be internal
Entities and Value objects must be sealed
Controllers can't depend on repositories directly
Command (or query) handlers must follow a naming convention

The possibilities are endless, and it's up to you how many design rules you want to enforce.

Here's how you can write tests for enforcing design rules.

Command handlers must end with CommandHandler

Controllers can't directly reference repositories

Takeaway

Architecture tests are an easy way to enforce software architecture and design rules with automated tests.

One of the best investments you can make as a software engineer is writing automated tests. You write the tests once, and use them to verify your system forever. Granted, you also have to maintain the tests over time as your system grows.

Manually enforcing software architecture with pair programming and constant PR reviews is:

Error prone
Time consuming
Not cost effective

Architecture tests really shine here, since you can write them quickly and reduce the cost of enforcing your software architecture rules to zero.

Thanks for reading.

Hope that was helpful!

Whenever you're ready, there are 3 ways I can help you 🎁

To access all of the source code that I use in my YouTube videos support me on Patreon
For more practical & in-depth coding examples subscribe to my YouTube channel
Promote yourself to 15.000+ subscribers by sponsoring this newsletter (booked out 2 months)

This week on YouTube ▶️

Everything You Need To Know About EF Core 8 Raw SQL Queries

The Best Way To Write Parameterized Tests In .NET Using xUnit

Want a better way to get the latest news? 📰

If you're tired of clickbait and partisanship in the news, consider a news aggregator called the Otherweb. It's free, ad-free and junk-free. Check it out here.

You received this email because you subscribed to our list. You can unsubscribe at any time.

Dragise Cvetkovica 2, Niš, 18000, Serbia

free NET service bus existing SQL Server serious Rebus users beautiful software architecture

MNW #036: Enforcing Software Architecture Rules With Architecture Tests

MNW #036: Enforcing Software Architecture With Architecture Tests

Writing Architecture Tests

Enforcing Architecture Rules

Enforcing Design Rules

Takeaway

Key phrases

Older messages

MNW #035: Health Checks In ASP.NET Core For Monitoring Your Applications

MNW #034: Idempotent Consumer - Handling Duplicate Messages

MNW #033: EF Core Raw SQL Queries

MNW #032: How To Use Rate Limiting In ASP .NET Core

MNW #031: Implementing The Saga Pattern With Rebus And RabbitMQ

You Might Also Like

Data Science Weekly - Issue 543

A deal made in cloud security heaven

💎 Issue 413 - RubyJS-Vite

💻 Issue 406 - Swift for C++ Practitioners, Part 1

💻 Issue 413 - How to implement HLS Video Streaming in a React App

📱 Issue 407 - Textual Healing: iOS Text Editing Minutiae

💻 Issue 413 - Interview with Senior JavaScript Developer 2024 [video]

💻 Issue 331 - 30+ app ideas with complete source code

💻 Issue 408 - Curl: Hyper, is it worth it?

📱 Issue 410 - Swift for C++ Practitioners, Part 1