You wouldn’t believe how the cold dark winters evening simply fly by here (well at least I managed to get home even though 4″ (100mm for the metricians) of snow fell this afty, the first November neige in Geneva since 1980 allegedly). And its still dumping it down – might have to throw a sickie tomorrow and go sledging with the kids.
Anyway the big argument today was test code.
Should you or should you not put your VBA test code into production?
Should you strip down your project to the absolute minimum clean prod only code?
Or should you leave in the code you used to test your production code? (assuming you are one of the 3 VBA devs worldwide who bothers to test of course)
My vote is to leave it in, and even though I was in the minority at school today that doesn’t mean I’m wrong, yet.
If your test code is crappy and distracting then yep take it out, no probs (in fact take out all the crappy distracting code), but why I think decent test harness code should be left in:
- It helps show what the code is meant to do
- It helps when you are trying to fix something later in production at a users’ desk.
- It shows that someone did some testing sometime
- If you make significant edits to your code you should retest, if that edit was removing what you thought was the test code how will you check you haven’t broken something? add a test harness???
What do you think? what am I missing that these clean code freaks can see? Remember I’m not for a minute suggesting leaving in a load of random junk scattered throughout a project. I’m thinking of separate modules or at least sections with a bunch of meaningful tests that exercise the main functionality of the system in a controlled way.
What do you do?
cheers
Simon