Unit Tests and Architecture Tests: Two Different Kinds of Safety Net
A broken layering rule should fail a test, not slip past a review.
Mert Celal Yılmaz · Full Stack Developer · Updated:
Seeing a piece of code work once is one thing. Knowing it still works six months later, after someone else has touched it, is another. That's what unit tests are for: you isolate a method or a handler, mock its dependencies, and check that a given input produces the expected output. Architecture tests work at a different level entirely, they don't check behavior, they check the dependency rules between layers, like making sure the Domain layer never references Infrastructure directly.
Automated testing is something I push for across the board, not just for individual features. On an apartment management system, working in a two-person team, we set up the code review process ourselves and used it to pin down what counted as acceptable code quality. In a team that small, a careless review is worse than in a bigger one, there's no third pair of eyes to catch what slipped through.
Architecture tests add another layer of safety on top of that. Instead of relying on someone spotting a layering violation during review, the build just fails the moment the rule is broken, not two weeks later when it's tangled into five other changes. Setting these up feels like extra work at first, then it quietly turns into insurance you stop thinking about.
In practice, architecture tests work by reflecting over compiled assemblies — a library like NetArchTest evaluates a rule such as 'Domain must not depend on Infrastructure' against the actual IL-level type references, not against the using statements in the source. On the apartment management system, that catches indirect dependencies hidden inside a method parameter or a private field that would be easy to miss just reading through the file by eye.
Writing an architecture test for every layering rule you can think of becomes its own maintenance problem on a smaller codebase — the more rules you add, the more brittle the suite gets, and every legitimate exception needs its own carve-out. With a two-person team we ended up drawing that line by keeping architecture tests for the handful of rules that are genuinely expensive to violate later, domain not depending on infrastructure being the main one, and leaving finer style and design calls to the regular review conversation.