Testability is contextual. The same code that was not testable yesterday, or rather hard to test, may be easier to test today.
As we’ve already said, everything is testable, it’s just a matter of motivation, effort and skill. And that effort part lends itself to the “easier to test” part.
Testability depends on many things, but we can divide it to:
- Operability – How easily we can call the tested code
- Observability – How easily we can observe the result or effect of the operation
- Controllability – How easily we can control the conditions of the test
- Reproducibility – How easily we can make sure the code executes repeatably
Today, it’s all about controllability.
Testability Is Where the Environment Is
We think about a test “structure” like this:
Simplified, of course. But in reality, it looks like this:
And I’m throwing a lot here into the environment. Configuration, the right dependencies, ports, gateway or not, proxies or not, and a whole lot of data. Oh, and maybe even a machine.
You see, before we had containers, younglings, we would need to setup a real machine for testing. Yes, in the cave! Those were the days.
Those days are not over, at least for folks working with hardware. Hardware availability (if required) raises and lowers testability.
But if all we need is emulation (and please remember, “the cloud” is hardware emulation), testing becomes easier. And with tooling, like Docker, or Kubernetes (and others), controlling the test environment becomes easier.
And that’s just the beginning. Because everything that happens before we run our test requires work. The provisioning of the machine, deployment of the application, configuring it, and setting it up – we need all this, for the test to tell us what we want.
We’re Off To See The Wizards
Let’s talk about Docker (and friends) first. Today, we use containers as test environemnt. Sometimes we don’t need to do anything – we just ask the DevOps gals & guys: “Build me a spec-ed machine”. And if we’re lucky, that’s most of the pain gone.
But if the DevOps wizards are not available, we can YAML out within minutes (or a bit more), something that would take hours or days before.
And if we needed changes – it’s easy. That’s controllability. The more we have it, we perceive the system as more testable.
But we got our own magic to perform. Let’s say our wizards have gifted us the machine, and all we need is to set up data in the database. That’s for every test, so setting up data includes both preparing the data, loading it into the database, and cleaning up after we’re done – for every test.
Now depending on tools, skills, and the database admin, this can be easy job or not. If we know SQL, it’s probably on the simple side – although maybe not easy. Preparing data without proper tools, and sometimes with their help can be an error-prone process. Which means, it may take a while, until we’ve got all our data scripts in order.
That goes for everything we need to prepare – that YAML, reference data, setup data, configuration files – everything. The more work to be done, we see the system as less testable, because who in their right mind will go on such a trek?
Testability is in the Eye of the Controller
Testability, or our view of how easy to test, is not just directly related to the operation and observation capabilities. Our ability to control and setup the environment and prerequisites adds to our evaluation of a system’s testability.
That’s controllability. Next time, reproducibility.
Check out the my API testing and Clean Code workshops where I discuss testability:
0 Comments