I have a love/hate relationship with test driven development and unit testing.
I’ve been both an ardent supporter of these “best practices,” but I’ve also been more than skeptical of their use.
One of the big problems in software development is when developers—or sometimes managers—who mean well apply “best practices” simply because they are best practices and don’t understand their reason or actual use.
To check out John’s first article on software development methodologies, please go here.
One of my first official jobs in the software development industry was that of a tester.
My job entailed looking at stacks of papers that were printed out by a new printer we were testing at HP and comparing them to the “master” printouts produced by older printers.
I didn’t actually do the comparison of the pages myself; instead, I would execute the tests, someone else would compare the printouts, and I’d look at the differences they flagged.
With each difference, I would review and decide, based on the test, whether the result was a true failure or defect. If it was the latter, I’d write up a defect report for a developer to look at—and possibly fix.
The following is an excerpt from The Complete Software Developer’s Career Guide by John Sonmez. To get the entire book delivered to your inbox, go here.
Are you ready to put on your boxing gloves and enter the ring?
Are you ready to be confused?
Are you ready to endlessly debate semantics? To hire expensive consultants to tell you what you are doing wrong and coach your team to higher levels by getting everyone “certified?”
Well, welcome to the world of software development methodologies.