Let’s talk about languages and clean tests. We use langauges all the time. I’m using one right now! And you can understand me, because you know the same one too!
Amazing!!
Ok, I know this seems trivial, but in automated tests we use other languages. And I’m not talking about programming languages.
Here’s an example.
This is a regular web test. We all can understand what it’s doing, right?
The reason is, we were taught that web tests are about elements and their operation – clicking, checking and unchecking, enabling and disabling.
What’s the story?
So, the test is readable, but does it tell the story of the application? Let’s look at the app.
Checking the “I’ve read the whole terms sheet and agree” checkbox, enables the “Register” button,
and un-checking it disables the button.
While our test checks the operation, it doesn’t tell us about the meaning. Sure, as I’m writing it, it will look to me that everyone will understand. But let a week or two pass by, I won’t even remember. With more complex tests, that’s a recipe for errors, misfortune and despair. Which could lead to violence in extreme cases.
The Language of Tech
We do that all the time. We use a framework or two, in this case it’s Playwright, to write the test. But it can be with any framework – for API calls, logging, reporting.
Every framework we use, is intended for a wide range of applications. It doesn’t know our terms, our domain. That’s why it uses a language of it’s own. And it’s usually very technical.
In our test it’s elements, “clicking”, “filling”. Even the terms “Enabled” or “Disabled”, are really technical, we’re just so used to them, they seem part of the domain.
I can change the name of the test, to explain its purpose, like this:
That’s better. This is usually as far as we get to describe what is going on here.
But with more complex tests, that will probably not work. I’ll need many comments to explain what’s happening.
Clean tests tell stories
Or I can rewrite the test like this:
Now the test’s intention, or really mine, is a lot clearer. I expect people to understand, even the non-technical ones. I can check that when my test gets reviewed.
Our tests can contain multiple languages. We usually mix the technical language with the domain language. While it’s easy to write (or spaghetti-monster-in-the-sky helps us – generate) the first language, using the domain language lowers the risk of misunderstanding and bugs. Not to mention maintainability.
And that’s a good place to remind everyone, that writing tests, clearly (and cleanly) is part of the “Clean Tests” workshop. Check it out.
0 Comments