Testability

As explained in Go by Example

Testability is the degree to which software can be tested effectively and independently.

Testability is the degree to which software can be tested effectively and independently. It comes from code that exposes controllable inputs, observable outputs, and replaceable dependencies. Tests then do more than find defects: they reveal whether code is easy to interact with, adapt, and maintain as requirements change. section 1.1.3 section 5.6

Code becomes difficult to test when it relies on globals, hides side effects, or offers no explicit inputs or results. A CLI main function illustrates the problem: it reads os.Args and writes through os.Stdout or os.Stderr, all outside direct test control. Changing shared globals in tests can also complicate parallel execution and contribute to flaky tests. section 5.1 section 5.2

Make behavior easier to test by restructuring dependencies rather than patching global state:

• Extract business logic from a black-box entry point into a function with explicit parameters, such as run. section 5.2 section 5.2.1
• Pass an environment object containing dependencies, so production supplies real globals and tests supply controlled fakes. section 5.2.1
• Use abstractions such as io.Writer to capture output in in-memory buffers during tests. section 5.2.1 section 5.6
• Depend on a small interface defined for the behavior a consumer needs, then substitute a fake implementation in tests. section 1.5.3 section 10.4.1
• Balance fast, precise unit tests using test doubles with tests against real components for realistic correctness checks. section 7.8 section 5.6

Refactoring a CLI without changing its behavior

Keep main as a thin production wrapper and move its work into run(env). The production path fills env with real arguments and streams; a test passes fake arguments and in-memory writers, then checks output and errors directly. The CLI can still launch normally and report invalid flags, while its core behavior becomes straightforward to exercise automatically. section 5.2.1 section 5.3.4

Interfaces need not be designed in advance. When code must avoid a live payment service, declare a local Charger interface with only Charge, accept it as a dependency, and provide a FakeCharger in tests. Any type implementing Charge can serve as the real or fake dependency, even if the third-party API declared no interface. section 1.5.3

Figure 5.2 Moving main's code into a run function that accepts an *env struct. The env struct has fields for us to inject the global variables, such as the os.Stdout. This approach allows main to inject real globals to run, and tests can inject controlled fakes that we can observe from tests later.

The diagram shows the central testability boundary: main supplies real global dependencies, while tests supply observable, controlled replacements through env. section 5.2.1

Testability is not identical to coverage or a prescribed workflow. Touching every line does not test every path or guarantee a bug-free program, and testing may occur before, alongside, or after implementation. The practical goal is code whose dependencies and effects can be isolated while preserving useful high-level checks. section 1.1.3 section 7.8

How Go by Example covers it

How deep it goes

Works through CLI refactoring, injected environments, fakes, and interface-based substitution rather than only defining the term.

Examples

Uses a HIT command-line tool, in-memory output buffers, invalid flags, and a fake Mithril payment charger.

What it assumes

Assumes basic Go interfaces before applying dependency-injection techniques to CLI code.

What you can do after

Apply it by extracting logic, injecting dependencies, and substituting fakes while retaining production behavior.

How it connects

Connects dependency injection, implicit interfaces, io.Writer, global state, test doubles, and unit testing.

liveBookmanning.com

Read Go by Example on liveBook Get the book at manning.com

Also explained in

• 

  liveBookmanning.com
  Functional Design and Architecture: Examples in HaskellTestability is the degree to which software can be evaluated effectively through automated or systematic tests.
• 

  liveBookmanning.com
  Software Testing with Generative AIThe degree to which a product's behavior and internal or external interfaces support effective testing.

Compare how 3 books explain testability →

Related concepts

• quality attributekind of · A quality attribute is a measurable or testable nonfunctional property that characterizes how well a software system meets stakeholder needs beyond its basic functionality.
• dependency injectionproduced by · Dependency injection is a software design technique in which a component receives its dependencies from outside rather than creating or locating them internally.
• couplingproduced by · Coupling is the degree of dependency between software components, including how their behavior, availability, or changes affect one another.
• dependency inversionaddressed by · Dependency inversion is a design principle in which high-level policy and low-level implementation depend on abstractions rather than directly on each other.
• pure functionproduced by · A pure function is a function whose output is determined solely by its explicit inputs and whose evaluation has no externally observable side effects.
• hexagonal architectureproduced by · Hexagonal architecture is a software architecture pattern that isolates an application’s core logic from external systems through ports and adapters.

This explainer was generated by Manning's knowledge graph from the text of Go by Example. The section links point to the parts of the book it draws on.