August 09, 2012
Coding Session #15: Testing
(Should have put a million monkeys in that room. Would have at least gotten Macbeth out of the deal.)
Where was I? Oh yea…testing.
I want to smack whoever started the rumor that rigid testing processes are the way to make coders write good code. And by extension, the perfect application is produced as a result.
First of all, there is no such thing as "good code". Because applications are worse than stone tools and the goddamn !@#$ing browser is well...MANY goddamn !@#$ing browsers. So there is only "survival code". Code that you know will never be looked at again unless it is responsible for bringing down a nuclear reactor.
(There was this old man named Rip van Winkle who ran into some people while trolling CompuServe and was enticed into writing "good code". He emerged from his basement 20 years later to find that COBOL was dead. Along with his dog. Everyone was jealous that he missed out on Java. True story.)
Secondly, an application that passes all testing processes is still likely (90% likely) to be complete crap. I say this with confidence because 90% of the applications that I see people using to run businesses with are complete crap.
Thirdly, testing is more tedious and boring than sanding and painting a house. How many people like sanding and painting a house? We still do it, but not if we can afford to pay someone else before it falls down. My rule of thumb: every hour you force a programmer to test means five hours of survival coding lost. Every hour a non-programmer tests…ten hours of survival coding lost.
Lastly, writing test cases is actually what speccing and wireframing an application is supposed to do. Redundancy may be good for space shuttle systems but it just gives the afore mentioned mythical beasts constipation. I'd rather get paid on a regular schedule.
Our solution to testing? Do everything we can to avoid testing until we absolutely have to:
1- Be really good at speccing and wireframing
2- Compartmentalize code (https://www.data-mosaic.com/sutras/cms/documentation/architecture/modules)
3- Architect solutions in business layers (a whole other subject)
4- Use an IDE (https://www.servoy.com)
5- Cheat like hell: never write your own code if you can use someone else's
6- Only solve one thing at a time when creating a function (you'd think this one would be obvious...)
7- Code socially (team programming, code reviews, source code repositories, trello boards, etc)
8- Never leave home without your handy big red panic rollback button
When the dreaded day of testing does come:
1- Grab a bottle of wine
2- Rope your peers into helping you test by bribing with bottle of wine
3- Test to break your application, not to click everything
4- Record the testing session and put up it on YouTube
5- If nothing is broken (and sometimes even if broken), make your users test the rest
6- Repeat often. (Think of it as an excuse to drink more)
End result, lot's of creative survival code not inhibited by testing bullshit (*cough* JUnit...) written so that civilization as we know it doesn't have to go back to sharpening rocks to record business activities on clay tablets.
My point? Obvious bugs are easily found without the hassle of unit tests. Conversely, no amount of coded unit testing will find the truly devious bugs. These bad boys are only found by sending sacrificial lemmings out in all directions on a glacier and noting which ones fall through the ice. (Lemmings taste like chicken.) So...take testing with a grain of salt like everything else and don't over-engineer the process.
If only the IRS hadn't quit accepting clay tablets several thousand years ago.
(Note: video gets a lot more geeky and interesting around the 22 minute mark when Troy joins in.)
The comments to this entry are closed.