Some call them flaky tests. Some call them fragile tests. Or unstable. I say it’s neither, it’s the code. Nobody likes them, regardless.
But here’s something interesting I heard in a conversation with one of my clients.
He said: “I like calling them flaky tests, not fragile”.
Why? I asked. They mean exactly the same thing.
Ah, that’s true, said the developer. But it sounds different.
“Fragile tests” sounds like being fragile is the intrinsic property of the tests. They are just like that, there’s nothing we can do about it, and we’ll just have to live with them like that.
“Flaky tests” sounds a little different. It sounds like someone (not pointing fingers here, but you know who you are) hasn’t done enough to remove the flakiness. It is not a part of the test, it is something that clung to it, like what you’re thinking about right now. And it can (and should) be removed.
In other words, “fragile tests” don’t sound like they carry responsibility, while “flaky tests” do.
I liked this explanation. The responsibility for stability and consistency is there regardless of how we call it (whether it is in the code, test, or both).
It’s just in one case, if you listen closely, you’ll hear the test whispering to you: “Don’t leave me like that. Fix us”.
And it is our responsibility.
For more a-fixing tests, and testability improvement, check out my “API Testing for developers” workshop. Because we are responsible developers, yes we are.
0 Comments