We all know about clean code (I’m assuming). Clean code is great! Clean tests are great, too.
Here’s the truth about it. We don’t really want clean code. But we do need it.
If we would write code once, and never need to look at it again, we could write it anyway we want. Assuming it works.
But in reality, we’ll need to get into this code again. For extending it, or for fixing bugs (maybe that assumption was a bit incorrect). And when we do, we’d like to do it as quickly and safely as possible. Get in, do the change, and get out (before everything blows up, or the testers find it).
That’s where clean code helps. Investing in the code with good names, separation and abstraction, NOW, will help us make the future task shorter, LATER.
Clean Code? Pffft. How About Clean Tests?
This leads us to clean tests, which almost nobody talks about. When a test breaks, what would be our entry point to the code? The Test! Don’t we want to find the problem and fix it quickly?
Then why do we not apply the same clean code standards to tests?
We should. It’s just, once we write a test and it passes, it seems more important to move to the next one. And what do we do with the next one?
We want to get rid of the chore, quickly, of course,. So we copy the one we just completed, warts and all, and change it a bit for the next case.
One of clean code principles is no duplication. Well, we’ve just ran through that one with a truck.
Of course, if we remove that duplication later, we’re good. But who does that? Except me?
If we agree that tests are first-class code, we need to treat them the same as any first-class code. Oh, and if you don’t practice clean code, then you probably do treat tests the same.
Having clean tests will help with our goals when fixing bugs, or extending existing code. Tests help us understand different scenarios in code better. If the tests are clean, we’ll get there quicker and safer.
So, Clean all the tests!
How do you do that? For example, there’s my cool “Clean Tests” workshop, start there!
0 Comments