Programming Tips #2 “Test, Test, Test”

If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!

managermaths.jpg

Something that I see all the time is programmers who do not test their own work. I don’t know if this is laziness, stupidity or they really do believe what they have written is going to work. Point of fact “NOTHING EVER WORKS”, in fact as I have stated in previous posts if I write more than 10 lines of code and it ‘just works’ I get very suspicious that there is in fact something hidden away that is potentially much more dangerous than just an obvious bug.

Laziness, this is the worst reason ever, if you cannot be bothered to test it yourself you are going to end up with more work because at some point someone will find a problem with what you have done and make you fix it. So is it better to fix it while the code is fresh in your brain or later when you have moved onto something else?

I am not going to advocate any of the common testing methodologies as I don’t personally use any of them (I write perfect code remember) but I do enforce certain practices on others if they cannot self impose certain standards.

A Short (Cough) story

What I always suggest to others is to get into a mental state that your code is going to be under constant attack. I will give you an example (and maybe it will explain why I code the way I do now.), my first published game was a side scrolling strategy game called ‘King Arthurs World’, it had this fun little feature that allowed the engineers in the game to drop barrels into pits for others to walk across.

Because it was quite a open play style game these engineers could also drop barrels off anything else they liked (e.g. cliffs, roof of buildings). You could then set light to the barrels, at this point the fire would spread from one barrel to another until all barrels that were touching were alight. This was all well and good except for when it came to the publisher testing it.

One morning one of the other programmers on the project came up to me and said something along the lines of ‘you won’t believe this’ and handed me a video cassette (the testers back then would video as they played to show us how they broke it).

Mad Testers

The testers (bless them) had spent hours dropping barrels off a cliff into a chasm below which for any normal person would be fruitless as it required about 500 barrels (and for each barrel you had take your little ban back and forth on the map to go collect another barrel) to fill up enough to then set light.

A Bug? Never!

BUT, at this point the system did not like you setting light to 500 barrels at once as it required a lot of object space to allocate to all them flames that spread out over the barrels. So to cut this short, they basically found a bug! (not one any other sane people would fine) but a bug nonetheless.

So word to the wise, someone will always find a way to break your code, so do you best to make sure you fix things before they happen.

Competition

If you haven’t already read the post I am looking for others to submit their best ‘tips’ on programming read the details here.

There Are 3 Responses So Far. »

  1. That is, I think, a main problem of most of the programmers including myself. I personally do not like testing a lot. I tend to test following my own imagination how something should work and that is mostly not matching the users’ way of using it. So I usually go for speed, do my work, test a bit for basic functionality and then send it for testing. 6-8 out of 10 works the rest I get back for fixing.
    Bad behavior. No wonder the testers don’t like it, but as long as I’m efficient, I rarely get complaints :)

  2. It’s like a counter-argument :)

    I am not going to advocate any of the common testing methodologies as I don’t personally use any of them (I write perfect code remember) but I do enforce certain practices on others if they cannot self impose certain standards.

    But seriously, if you don’t follow a common testing methodology (or X Driven methodology for designing) then how does anyone else figure out anything from whatever you are doing. There’s a lot of value to using a common system others already understand (even if only in passing).

  3. Padraic, All I was saying was I don’t use any of the ‘predefined’ methodologies but I do use ‘what nick has learnt’ which is a mashup of working under or trying out other peoples systems and finding my happy medium. This then is enforced at varying degrees based upon the experience of other team members and also what role I play within the team and what common systems/metholodogies they have worked with before.

Post a Response