On the design of testable systems, Rechtin provides us with several heuristics [Rechtin, 1991] -

To be tested, a system must be designed to be tested

This sounds self-evident, yet, within many architecture silos, a view persists that testability is the concern of development and testing teams. Are they missing something?

The test setup for a system is itself a system

Designing systems for testability is not trivial. It's a role performed by many development leads, often inadvertently, as a "side effect"of employing TDD. xUnit Test Patterns [Meszaros, 2007] is a catalogue of design thinking on how to architect large bodies of maintainable test code.

...for a system to meet its acceptance criteria to the satisfaction of all parties, it must be architected, designed and built to do so - no more and no less.

In software intensive systems, it is therefore necessary for us to design the means by which systems can be evolved and extended via executable specification.

Correctness

So, let's start to design something now! Let's design a correct system. We might describe correctness as the ability of a system to demonstrate it is performing to specification. If we consider systems testing to their specification boundaries, we see that the location of specification is critical to the correctness of the system (pls. excuse crap whiteboard drawing) -

• On the left, if we test only to our own internal specification, and our neighbouring systems do likewise, this introduces a specification gap. Internal specification includes stubs or fakes that we create, in order to isolate ourselves from external dependencies. Systems with a specification gaps will tend to exhibit limited levels of correctness, according to the dimension of the gap.
• On the right, if we test to a shared, mutual specification (in other words, a pact), this has the effect of minimizing the specification gap, with each component then being able to verify its own correctness, at minimal cost.
  

In conclusion, systems implementing a 'mutual specification' ('mute-spec'?) approach will tend to be more correct. Further, mute-spec systems are logically no longer monolithic, because they are now made up of high quality, individually releasable components.

[Meszaros, 2007] xUnit Test Patterns - Refactoring Test Code, Gerard Meszaros, Addison-Wesley, 2007.
[Rechtin, 1991] Systems Architecting, Creating and Building Complex Systems, Eberhardt Rechtin, Prentice Hall, 1991.