Back when I started on the long and windy road of Software Development, nobody ever seemed to talk about Automated Software testing. None of the articles or books I read about mentioned anything about “Test driven development” or even “Unit Testing”.
In fact, the only testing I heard about was getting a load of people to test your software and send feedback.
Quite often I would encounter stupid bugs during development which made no sense, which could in the worst case scenario take weeks to track down and resolve.
Why did it take so long? Because typically I was following this methodology:
- Step through code in debugger, find problematic line.
- Assume everything not related to the said line(s) worked perfectly.
- Spend an extortionate amount of time tweaking lines wondering why “impossible” things were happening based on incorrect assumptions.
And when I got problems such as heap corruption… that was not a pretty sight!
Really, the first time I heard about things such as “Unit Testing” was back when I started working with “Ruby on Rails”. A lot of rails developers seemed to be bragging about using “Unit Testing”, “rspec”, or even “Behaviour Driven Development”.
However my C++ game developer driven background kicked in and I failed to see the usefulness of such testing. I reasoned:
- “Automated Software testing doesn’t work well for games, they need REAL people to test them”
- ”I’m too busy writing code to make tests for it!”
- “If I write code once and it works, I shouldn’t need to check it works again”
The turning point
Once I started to work with larger teams however, things like this started to happen:
- Checked in code, works perfectly
- Other guy checks in code, unrelated code breaks
- Other guy fails to notice everything else broke
When working with a large team, you simply cannot count on everyone knowing as much about the code as you. If something they are not working on breaks, nobody notices. That is where Automated Software Testing comes in handy!
It was about this time that I noticed I was growing tired of dealing with countless numbers of regressions and bizarre bugs with my own projects. Sometimes the stupidest mistake when developing would go unnoticed for months.
Then of course after fixing the stupid mistakes, others would crop up – an endless cycle of stamping out fires!
I simply could no longer reasonably dedicate time to haphazardly fixing all these problems, so I caved in and started to take automated software testing more seriously.
Now I can safely say I feel more saner and confident that my code works as it should. I no longer fret about people changing code, since when it is covered by a test they will have to make sure it still works as intended.
So if you want to keep your sanity developing software, be sure to use automated software testing too!