Many of us had courses, attended lectures and speeches on programming. Many of us read (even many) programming books, and regularly read articles and blogs about programming.
Have you ever thought of what should have been the first thing to learn in programming? The usual "variables, operators, data structures, classes, templates, metaprogramming, ..." or something else?
I've come to the conclusion that the most important thing, the first thing to learn, the one that if you're not familiar with you shouldn't even keep studying programming, is the answer to this question: "How can I verify my code works?".
If I was a teacher, right before writing my name on the blackboard (yes, this is how I like it to imagine it), I'd write this: "How can I verify my code works?".
And I'll spend the entire lesson waiting for someone to come up with a reasonable solution. If nobody goes close to it, I'd assign it as an essay for the following lesson.
The concept I want to stress here is simple: The Code You Write Must Be Automatically Testable.
Emphasis on: Testable.
Emphasis on: Automatic.
1. At any given moment, you must be able to launch a script and verify that your code works as expected, while the result of the verification is automatically checked (refer to Unit Testing). Better if the script is fast.
2. Before changing your code, you must first write the tests to verify your changes will do what you expect (this is called TDD, Test Driven Development - there are many interesting and well written articles on this topic). Those tests will fail: your job will be making them pass.
3. You must not commit changes when some of the tests fail.
4. You must not build a package when some of the tests fail.
5. You must not be happy until all your tests pass.
(As a collateral note, you should beware of programming languages that don't provide mature and well maintained tools for unit testing.)
What happens if you don't follow this approach? Well, you will be able to write your code, have fun with it, pass your exams or even get paid for it, but sooner or later you'll end up with one or more of these questions:
"When did I break this?"
"How happened I didn't realize this wasn't working?"
"Now what else am I going to break if I add this new feature?"
"How can I test those 10K lines of code, without touching them?"
"How comes the testing guys never invite me for a beer?"
Inside the brilliant Head First - Software Development, you find the description of this simple process:
1. Write the tests
2. Make the code work
3. Refactor
4. Back to 1
On the Perl side, "Extreme Perl" gives a pragmatic view of testing.
Things start to get more complicated when the application you're writing has to interact with other "external" entities, which may be even remote. I'll write on this in the future.