Why you should use Architecture Tests in .NET

Introduction

Tests can arguably be more important than the code itself. You always get asked about your test coverage, what tests do you use, how did you implement them… People even discuss the famous Pyramid of Tests and try to implement as much as they can in their codebase.

Architecture Tests are like the hidden distant cousin nobody knows about. They are not even mentioned in the Pyramid of Tests and are forgotten most of the time.

Yet I have worked on some projects where these tests actually saved the day on multiple occasions. We had a lot of turnovers, with 2 internships welcoming periods. Also, hiring Seniors is generally more painful than juniors so the company would opt for that most of the time.

Why does it matter

In short, your team is mostly fresh and junior and if you’re working on a complex high scale application, you’ll basically always do the heavy lifting and double checking that all the standards you defined are actually being applied. Project references and dependencies, naming conventions, project structure and organization etc…

Instead of checking every PR, you can automate that in some sort of critical tests that are triggered and check for those things. I used Architecture tests for the following:

• Project References

Working in the Clean Architecture, we needed to keep each layer isolated as it should be. For a junior with no prior knowledge, an ALT-ENTER on Visual Studio can make him reference projects and shoot himself in the foot. Spotting those things can sometimes be tricky and time consuming so automating that was a big plus !

• Naming Conventions

When you structure your solution’s files, you have some sort of consistency to keep up with. API Controllers should be suffixed with the Controllers, Application Services with Services, Repositories, Extensions… Unit of Work or Vertical Slicing, you always have a consistent group that should be maintained. Having someone forgetting those names will drive you crazy and you’ll easily end up with a lot to change.

• Library Taboos

This one is a bit niche but still. When you’re working in the banking industry, you are sometimes restricted and forbidden from using certain libraries. Even OS, there’s sometimes a manual security check process that makes sure this library is safe to use. You can’t and shouldn’t keep track of this list.

We fetched to list from an API and tested our dependencies against this list. You will get surprised on how much time this test failed and saved us from the audit. Newcomers think they can install any library if it does the job and I mean I would be okay with it but it’s not my call.

• Enforce Testing

This sound strange but, you can actually use those tests to enforce some testing convention. We did somewhat that by implementing a test that search and check if each service has its own tests. I don’t think this is very informative and can backfire but still, you can always find the most critical things to test and enforce that which is awesome.

• Dependencies Versioning

In the .NET world with the recent and great advancements, there’s a lot of packages confusion involving .NET Core and .NET. While libraries can be backward compatible, it’s not recommended to install EF 6 on .NET 2.2 for example. For the new dotnetters, things can get a little messy knowing which version to install and why. Install latest does not always work sadly and testing some version patterns saved us plenty of debugging time with what went wrong.

How

That’s all great and everything, but how do you get started with .NET? There’s a Java borrowed concept and library called NetArchTest in .NET. This is an open source library. You can easily get started with their fluent API.

Here’s a borrowed example to check that all your interfaces are sealed (feel free to check the docs !):

// All the service classes should be sealed
result = Types.InCurrentDomain()
         .That().ImplementInterface(typeof(IWidgetService))
         .Should().BeSealed()
         .GetResult()
         .IsSuccessful;

Conclusion

Architecture Tests can be very useful in .NET. They can let you enforce some rules and conventions in your project, this will help you save time and manage more people on your team.

With that in mind, the developer that failed the test will be autonomous enough to see why it failed and understand the concept on his own which is also great.

Don’t forget to support this great library by giving a star on Github. I would love to have some feedback from people that integrated that in their pipelines!