Devlico.Us
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @devlicious

Derik Whittaker

Thoughts on Software Development, .Net, OOP, Design Patterns and all things cool



Testing is hard but debugging just sucks A$$

In my last post (here) I was giving a wrap up of the Mocking session I recently did at TriNug.  In that post I gave some of the reasons (sorry, I meant excuses) people gave for not doing any type of automated testing during their dally development ritual (notice I am staying away from TDD at this point).  I thought that those topics would be better suited to be broken out into their own post.

At the users group I asked the question to the group 'who creates automated tests as part of their daily development cycle?'.  After I asked this question I followed it up with, and if you don't WHY, WHY, WHY, WHY......  Below are some of the answers I received (btw, not the first time I have heard these reasons).

Reason #1 - It is too hard to get started:

Point: This statement is nothing new, I hear this all the time.  To be honest I agree with them, testing is hard.  It takes time and effort to learn how to do it.

Counter Point: But if you think learning to write tests and learning how to create testable code is hard, then what do you do when you need to learn a new product?  I can break it down like this.  Testing == Coding and Coding == REAL FREAKING HARD.  Stop using 'testing is hard' as a crutch and just give it a shot.

Reason #2 - My client/company is not paying me to write tests:

Point: This one always make me laugh.  Since testing does take time (not going to sugar coat this at all), and can slow down your pace of development, many people feel that they are not being paid to create tests.

Counter Point:  This one is real simple, ask your self these two questions. 

  1. Am I being paid to produce quality or crap? 
  2. Am I being paid to debug? 

I am going to assume that both of those answers are NO, and if they are not then I would suggest you stop reading this post as it does not get any better from here. 

Now that we are on the same page and we understand you are being paid to produce quality code why would you not want to do everything you can to bake that quality into your code up front?  This can happen with tests.  Take the time, take the challenge and create some tests.  Trust me, no one ever got fired for being a bit late with an application that was freaking solid from a quality standpoint (and if you do get fired because of it just look at it this way, you have a new and marketable skill to help you find your new job).

Reason #3 - I do not have time

Point: Testing takes time, and when time is short people throw every 'non-critical' functions out the window.  And sadly people think that quality is a non-critical function.  To prove this point just take a look at 90% of the applications out there... they suck ASS

Counter Point:  Just ask yourself this question.  Would I rather spend what little time I have creating tests to help ensure I have quality or would I rather spend time later stepping through code via the debugger looking for the bug I could have caught/fixed earlier?  If you would rather spend time in the debugger, then more power to you.

NOTE: Do NOT take the above statement as me saying that testers NEVER debug, they do but just a TON less than others.

Reason #4 - My code will not allow me to tests

Point:  This is one may be the only excuse that has some merit.  Poor code is hard to test. 

Counter Point:  Simply because you do not need to retrofit your entire code base at one time.  If you have 'bad' code that is easy to test that is fine.  Start testing with NEW code.  Hopefully you will not be creating bad code once you understand your current code is not the best.  You will also come to understand that when you start testing your code will start to get a little cleaner.  Finally, if you really want to start to test your legacy code, go out and pick up 'Working Effectively w/ Legacy Code' by Michael Feathers

 

As you can tell from my tone, I do not buy into any of these reasons, sorry excuses.  I wish that when I ask people this question and they gave me a response they would simply state the truth.  And the truth is people do not test for the following 2 reasons

Reason #1 - They do not believe that creating tests will improve their code
If this is what you really think, that is fine.  You are allowed to have your beliefs and I am allowed to have mine.  As long as we understand each other we can get along just fine.

Reason #2 - They are lazy
Not sure I need to explain this one.

Let the flames begin :)

Till next time,



Comments

Eber Irigoyen said:

I have a better reason

I write good code that works the first time

J

# November 14, 2008 8:22 PM

jdn said:

It is possible to create quality code without tests, and it is possible to create lesser quality code with tests (specifically of the 'bad' variety).

Since I know you, I'm sure you do a better job of presenting it in person, but you make it seem like you aren't aware of the previous point in your post.  

And while I am a firm believer of 'You can get more with a kind word and a two by four, than you can with just a kind word', you might want to consider not suggesting that you can't produce quality code without testing, since that will just turn some people off to your message.

Missed you at the Nov Chicago Alt.NET meeting (know you are NC-bound).  Wanted to heckle you about something.

YMMV.  HTH.

# November 14, 2008 8:58 PM

Jon said:

My employer does not pay me to write quality code... I struggle with this on a DAILY basis and they just don't get it. The mentality there is I want an application ASAP (sometimes day of).

# November 14, 2008 9:18 PM

DotNetKicks.com said:

You've been kicked (a good thing) - Trackback from DotNetKicks.com

# November 15, 2008 5:40 AM

Grant Palin said:

#4 is where I'm at right now, but I'm trying to work around it. I have an existing project that was not built with testability in mind - this was before I began my recent best practices learning spree - but have been slowly getting under test in recent times.

I've got a lot of code that is difficult to test because it touches the database, or the filesystem, or HttpContext. It's a work in progress, although an intimidating one. I'm using Feathers' book as a guide to refactor code to a more testable state. Will probably need to start some DI soon.

# November 15, 2008 3:38 PM

Christopher Bennage said:

I'm with you, Derik.

Writing code for testability has afforded tremendous improvements for me personally.

# November 15, 2008 4:56 PM

Dew Drop - Weekend Edition - November 15-16, 2008 | Alvin Ashcraft's Morning Dew said:

Pingback from  Dew Drop - Weekend Edition - November 15-16, 2008 | Alvin Ashcraft's Morning Dew

# November 15, 2008 9:43 PM

Dave Schinkel said:

>>>My employer does not pay me to write quality code... I struggle with this on a DAILY basis and they just don't get it. The mentality there is I want an application ASAP

Unfortunately, this sums up Corporate America and is why the US is going to go downhill.

# November 15, 2008 9:56 PM

Dave Schinkel said:

>>>Trust me, no one ever got fired for being a bit late with an application that was freaking solid from a quality standpoint

are you absolutely sure about that?  I am willing to bet based on the code & run corporate world IT lives in today, that people definitely have.

# November 15, 2008 9:59 PM

Dave Schinkel said:

I am 100% in agreement with Derik.  However again, the corporate arena and horrible management these days do not facilitate this type of culture or process in more IT shops I've come across myself.  Most of them with the exception of about 2 are piss poor and shit ass managers.

# November 15, 2008 10:01 PM

Ngu Soon Hui said:

The reason why testing and writing testable code aren't popular among the developers is simply because <a href="itscommonsensestupid.blogspot.com/.../testable-code-who-cares.html">the managers or the clients don't care about testable code</a>

# November 16, 2008 1:20 AM

David said:

I agree with Jon.

I could take my time and write well tested quality code and give the higher ups a flawless program in 3 months. Or I can hack together some buggy spaghetti and deliver in a few weeks.

The suits will always choose option 2 even if I explain that will be costlier in the long run.

inb4 quit your job - not in this economy

# November 17, 2008 3:17 PM

apluscoder said:

I have to disagree with your 'lazy' reason since if those people that you are referring to were lazy then they would test their code.  I am lazy and I do test.

# November 17, 2008 3:22 PM

Derik Whittaker said:

@jdn,

You and I have had this conversation before.  But I stand by my thoughts that having tests will produce higher quality on average across all teams.

@David,

Screw the economy.  Jobs are still plentiful (in our field) if you have the talent and the drive you can get a job with minimal effort (assuming you do not live in BFE).  Never lax on your morals simply because you fear your job or fear you cannot find a new one.  

My 2Cents

# November 17, 2008 3:31 PM

Reflective Perspective - Chris Alcock » The Morning Brew #225 said:

Pingback from  Reflective Perspective - Chris Alcock  &raquo; The Morning Brew #225

# November 17, 2008 10:57 PM

Rasmus Kromann-Larsen said:

Well said Derik,

Also regression tests (writing a test that fails before fixing a bug) really save you sometimes when "attempting" to reintroduce an old bug :-)

# November 18, 2008 3:15 AM

Niki said:

There's at least one more reason: There are some things that can't be automatically tested. That's no excuse to write no tests at all, but it's true anyway, and it has little to do with "poor code".

# November 18, 2008 3:45 AM

David said:

Derik,

Its one thing to take the moral high ground and risk your financial well being when it comes to Guantanamo Bay or something like that.

Its another thing to risk your financial well-being (and that of your family) for TDD.

# November 18, 2008 10:13 AM

Paul Kohler said:

Agreed 100%!

# November 18, 2008 9:20 PM

Joseph Rodrigez said:

TDD is hard! Especially when you are developing User interfaces.  Almost always it feels like its not worth spending that time while working in UI code.  Most of the examples out there talk about testing the business layers.

# November 20, 2008 3:36 AM

Charles said:

>>>Trust me, no one ever got fired for being a bit late with an application that was freaking solid from a quality standpoint

LOL. Plenty of people have. People I know have.

Corporations generally don't care about you writing quality code, they just want to see nice things on a screen in the least possible time.

Whenever I've worked for anyone else, you can talk them round at first, but soon they are back to demanding to see pretty pictures quickly and you can no longer afford to write tests.

My advice: Find a good idea, quit and do it yourself. Properly. Good quality is a long-term win. The other corps will get short-term wins and then find themselves with an epic fail.

# November 20, 2008 6:04 AM

Nivek said:

Management doesn't care about testing until there is a problem.  Then it's "What!  Why wasn't this bug caught during testing!"

A recent project (planned using waterfall), management calculated about a month worth of testing (developers had short iterations that included testing) over the project lifecycle.  Well, to 'streamline' the project and get it completed before the due date (management *loves* to get things done 'early') they removed the testing 'roadblock' saying "You can do that sort of thing later".  Now that the project is live, certain kinds of searching can bring the web site to a stop, lock up the database or worse (yea..think 'SQL Injection').  Like clockwork  .."How did these problems slip through testing!!?"

# November 21, 2008 11:46 AM

Dave Schinkel said:

>>>David

You don't risk that but you certainly DO NOT PUT UP WITH IT.  What I mean is, if you have any respect for yourself as a developer you would not stay in a code & run shop and just "put up" with a pile of shit.  You should start looking for a job and get the hell out for your own sanity and just development to become a better coder.

# December 18, 2008 11:47 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Derik Whittaker

Derik is a .Net Developer/Architect specializing in WinForms working out the northern suburbs of Chicago. He is also believer and advocate for Agile development including SCRUM, TDD, CI, etc.

When Derik is not writing code he can be found spending time with his wife and young son, climbing on his bouldering wall, watching sports (mostly baseball), and generally vegging out. Check out Devlicio.us!

Our Sponsors

Proudly Partnered With


This Blog

Syndication

News