I wonder when this trend of developers thinking it is not their responsibility to test their code started.
I started writing a response in agreement with Writing unit tests is your job so quit making excuses, when I realized I should blog instead.
In the 80s when first starting to write in a higher level language for production code, we were required to write unit tests. Using C was the first chance we had of running our code off of the hardware without using emulation software - it was so much easier when we could run tests at our desks. It was a very welcomed addition to our jobs.
Testing assembly code was time-consuming and extremely tedious
(though I did love doing it) which made it a huge expense. I enjoyed patching the code in the lab as I tested
(yes I know, I am a geek), but it was difficult to keep track of those patches and
update the source later. Once the source was changed, compiled, copied to tape,
and put onto the hardware – of course this was after scheduling time in the lab
to do so – it had to be re-tested.
After your code was tested and did what you expected it to
do, came integration testing. This was
very similar but not a solo task and was performed with coworkers to see if
your code actually worked with their code. Again this was an expensive part of
development.
QA’s function was to ensure the code did what it was
supposed to, not to see if it did what you thought it should do.It was not their job to neither find coding
bugs nor trap exceptions.
Today it still isn’t their job, QA has their hand’s full
doing validation and verification and all sorts of regression testing and
analysis among other things. The last
thing they need to spend their time doing is developer
testing, i.e. finding code and integration bugs.
Once QA enters the picture, the need comes to enter and
track all issues. This brings unnecessary work to QA and unnecessary work for
developers as the need to triage the bugs, fix the code, document the fix and
have QA retest.
Coding and testing are so much easier today – we have
automated test runners and special api syntax for expressing our tests. It still amazes me how easy it is to use a
test tool to call into a function without having to figure out the steps to get
there from higher up the code tree.
It is a developer’s
job to test their code. Untested code
should never be committed into a centralized version control system (if using dvcs
then of course you should and would – but that’s another topic). Doing so will cause your teammates to waste their
time catching and fixing your bugs, making it harder for them to get their own
job done.
Once when new to a project I asked my co-worker what we was used
to test the code. I figured he would give
me the name of a test framework. I was
taken aback when he told me – oh, we don’t have to test our code; we have a
great offshore QA team that will find all of the bugs. Well I wrote tests anyway – and yes the
fantastic QA group found bugs – but they were not code related. These bugs all pointed to places where I had
misunderstood a requirement or a requirement was unstated or not thought of. And I needed QA to help me solve them.
There is a concept I got long ago from a parenting tape*
that one should not ‘make
work’ for themselves or others. I
taught my kids this when they were little. If you have a spill and don’t clean it up or put something in a place
where it doesn’t belong, you have made ‘make work’. Make-work is unnecessary work
that wastes someone’s time, even your own. The spill will be harder to clean after setting there and you will need
to run around the house putting everything in its rightful place.
No testing will not make your code perfect, nor does it need
to. However it will save everyone time
and help your project to be successful. So please do not make-work. Better yet poka-yoke
your code.
maggie++
*Possibly from one of Barbara Coloroso's parenting
tapes or talks.