I don’t get tired of hearing that question, because if I did, I’d need to sleep for a couple of years. It usually comes up with unit tests, as developers prepare to test their day-old or year-old code.
That question has a couple of hidden assumptions that are easily crushed, but they still come up.
- The code works as it is.
Well, that may be true now, but then, why do you want to test it? If it works and you leave it alone, there’s no problem.
But that’s not the case, is it? You need unit tests because, either you know it doesn’t work, or you know you’ll need to change it soon, and then you’ll need to test it. And when you change it, it’s not really for the tests.
- The code so brittle you’re afraid to touch it
Well, that’s understandable. But again, you probably need to touch it anyway. And after you do, you want that code working.
- The design is so good it doesn’t need to change.
That’s a funny one. Because everyone talks about the problems of their legacy code, and how spaghetti-like it is. But when you need to test it, and you need to change it, because it won’t let you – then there’s suddenly a problem.
Let’s make it clear – when choosing between working code, with proof, or perfect- looking code (assuming it is), without proof – go with the first option. Always.
So, do you need to change the code for your tests?
No, you don’t. Not for the tests.
You need to change the code, because tests give you something you didn’t have before: proof that it works. Currently you don’t.
Let’s agree that the code really wasn’t that great before anyway, and it’s gonna be good soon.
So it’s ok. Change it.
And when it works, and you still don’t like how it looks, then you can refactor for that perfect design.
If you want to talk code and tests, and changing both, there’s a workshop for that. My Unit Testing and TDD workshop, in all languages and colors.
0 Comments