Let’s talk about knowledge, and where it goes, after you’ve walked away from the code. Sounds confusing, I know, but stay with me.
Ok, let’s look at an example. Here’s my demo app.
This is a registration app, as you can plainly see. But we’ll focus today on two features.
The first feature, is checking the “I have read the whole term sheet and agree”, the checkbox enables the “Register” button, and un-checking it disables the button (as it is presented in the picture).
Everybody knows, you can’t register if you haven’t enjoyed reading the whole term sheet, right?
The next feature, is the error message. If I click the button with all the text boxes empty, you’ll see an error message. You can’t register if you haven’t given the details.
Like this:
Once the error appeared, typing anything, in any of the text boxes, clears the error message. Like this:
It’s a usability feature. It’s like the software is reading your mind, and doesn’t show you the error any more, because you’re smart, and you won’t make the same mistake again. Right?
Right?
Anyway, what’s the common thread between these two features?
The tests will tell us
Maybe it’s not clear yet. Let me show you some tests. Here’s a test for enabling the button:
The test is pretty clear, isn’t it? You check the terms checkbox, and validate the button is enabled. Then un-check the checkbox, and validate the button is disabled.
We can see the application business logic in the test. You can’t register without checking the terms checkbox – It’s in Playwright-ese, but we can see it.
Ok, let’s take a look at the test for the error messages. What have we got here?
We can see the operations, but some of things here are missing some context.
Let me clear it up a bit, with adding some comments, and breaking lines.
That’s better. Now we have more context about what’s happening here. We can tell that we start off with checking the terms checkbox, because we wouldn’t be able to move on with testing the errors.
Then, we explain that if we don’t do anything with the boxes, they remain empty, because they started off empty. That will cause the error on validation. Finally we explain that typing something in any of the boxes clears up the error.
So, back to my question: What’s that common thread?
If you knew, you probably don’t now
It’s the things we know, and assume that other people know too. How the application behaves, and how that behavior is tied to how its built.
We always say (Ok, I say), that tests are a documentation of the application. Well, they are, but nobody promised they will be good documentation. We miss the connections and context, like the things I needed to explain in comments.
Imagine you saw the tests without the comments in two months. Would you remember all the connections and related behior between the terms checkbox and the button? Or typing and visible errors?
When we do test reviews, we should assume we won’t remember everything we did and know now. Use the tests to tell the story and the connections. How do we know we told a good story? The best way is to find someone who’s not connected directly to the work, and see if they read the same story from the test. They will tell you.
We think the next time we see the tests, we’ll be in the same mode of when we wrote them. That we’ll remember the little details, and all the micro contexts.
So, let’s assume we won’t. And let the tests help us remember. Let them be the savior of our knowledge.
Want to learn about storytelling in tests? Funnily enough I talk about that in my Playwright workshop. Ok, and stuff about automation too.
0 Comments