Tests Are Part Of Your Architecture

To me, tests are part of your system and its architecture, not a separate thing that's tacked on as an afterthought. As such, architectural principles that pervade the system must extend to the tests. Testability is an essential architectural characteristic that pervades the system.

For example, the test suites have to be cohesive, and the tests only lightly coupled to other system components. They must follow architectural rules like single-responsibility (test only one thing).

Liskov substitution (changes to the test are irrelevant to the clients, but more importantly, changes to the clients are irrelevant to the tests) is essential. When refactoring, for example, if the test must change because the client code changed, you have lost all safety. Tests must be implementation-independent. If changing the code breaks 100 tests, people resist necessary changes and refactoring. Business rules must be isolated into components so that, if they change, the test-change blast radius is minimized. Test via interfaces.

Basic abstraction requires an entity's implementation details to be hidden from other entities, including tests. Test behavior, not state. Tests that know how a client works under the covers are too delicate to be viable.

Testability is an essential architectural characteristic that pervades the system. You may have to define APIs or equivalents expressly for testing. These APIs also have to be secure. The last thing you need is some hacker using a test API as a backdoor. Test injection, if you use it, is an architectural concern.

Tests, like all other system components, cannot depend on volatile parts of the system insofar as that's possible. A worst-case example is a business logic test that depends on the GUI, which is typically very volatile. Change the GUI and the test breaks, even when the thing it actually tests (the underlying business logic) hasn't changed. Your architecture must isolate and separate the business logic from the GUI so you can test them independently. Indirectly testing anything through something else is always problematic—it exposes implementation and violates encapsulation.

These are just a few examples. My point is that tests are first-class citizens and that testing is integral to the entire architecture. They're there from the beginning, not something you add later.