Is there a testable architecture?

As I navigate towards other approaches of testing software, I see that there are some arguments in favor of testability. For example, cucumber names ports and adapter as a testable architecture [1].

In the fourth edition of the book “software architecture in practice” the chapter 12 dedicated to tstability elaborates on what might be a testable architecture and list its attributes rather than name a single architectural style.

The importance of listing attributes depicts a broader picture which leads to other architectures also being labeled as “testable” besides the ports and adapters.

In short, what the book depicts is a set of quality attributes that is the foundation to what is the book concept. Software architecture is made of attributes, those attributes are based on requirements that can be beyond the business requirements. Often the architecture besides tackling business needs it tackles complexity, tradeoffs, security and much more.

In that sense, answering the questions “is there a testable architecture?” becomes a questions that lacks structure from the start.

Let’s take the cucumber site as a basis to deconstruct to walk us through the gaps that the “testable architecture concept” has.

What is a testable architecture from cucumber website

In his talk (shared in the cucumber site) at Devlin 2017, Aslak Hellesoy shared what he thinks that makes a architecturable testable and the key points are the following:

  1. Inspire confidence
    • No test failing for some unknown reason
  2. lightening fast
    • Fast feedback with tests, if as a developer you have to wait a long time to have feedback, it impacts the delivery. It prevents improvements in the code base itself. Fast means under 15 seconds.
  3. Low cost
    • We are not paid to write tests we are paid to write features.


  1. [1], “Testable Architecture,” 2022 [Online]. Available at: [Accessed: 01-May-2022]