The other day I’ve stumbled upon the an article entitled “Testing is not a phase.” — It reads like a list of truisms. And then it came to me: Well, of course, we all do test-drive things! Let me explain.
Before doing anything we have an expectation of some kind, however vague. Then we carry on some actions. And then we check what happened, and make a conclusion of some kind.
Yes, this sounds like a truism too, but bear with me.
When we write some code, we expect it to produce something. We test even the hello-worlds: we execute it and look at the result in the console or in the browser. “Well, obviously!” you’ll say “What’s the big deal?!” Nothing. Just checking.
So now, once we’re clear that we already do test everything, the question remains: Are we going to do it manually, or instruct the computer to do it? I can test a hello-world manually, but as the program grows, the computer can test it much faster, won’t forget things, and will do it with a lot less effort.
The testing veterans would probably jump in to explain that “It’s not that simple!” Maybe. What I’m saying is that we shouldn’t make it sound like it’s some kind of Rocket Science because that works against the purpose. The essence is that it’s a Good Thing® to automate testing of our programs. Once we understand and accept this, everything else will begin to fall into place.
As we start doing it, questions will start popping up. And then we can invent or google answers.
* * *
What I’m trying to say here is that if we want answers to stick, we need to bring them up after the questions appear. If we’ll start with a policy like “AS OF TODAY, WE’LL TDD ALL THE THINGS!” it will work with as much success as our modern education system. If we try to poor wisdom in people’s brains, as valuable as it may be, it will only stick as much as it answers their questions.