"I don’t have time to test!"

Please pardon me while I rant a bit…

How many times have we heard this response when we press our co-workers to test the code they are writing.  This argument is often made when the team is up again tight deadlines and excessive pressure from management for delivery.  I’ve even made the argument myself before, but find it increasingly harder to say it with a straight face.

Way back in 2000 I was given a copy of “Extreme Programming Explained” as a going-away present.  I was leaving a research organization here in San Antonio to cut my teeth with a local start-up.  Our shop was reasonably mature (rated CMM-3) and I had learned quite a bit about Software Engineering in a relatively short period of time.  That said, the ideas in this books really got me thinking…and it seemed to help sate my hunger for a more lightweight process that would better fit my now environment.

Among the first practices that I started to grapple with was testing.  I had experience with SilkTest, but I wanted tests that were closer to individual units.  I first started with my own home-made test fixtures and had limited success…a few years later I was using VBUnit and NUnit..and I was becoming test infected.  In spite of my love for working with tested code, I still found myself arguing that I didn’t have time to test when under the gun.  It was about the 4 year mark that I began to shift my view.

Now, I think that abandoning testing due to time constraints is reckless and irresponsible.  I sometimes catch myself thinking that I don’t have time for test writing, but I soon find myself proving this argument wrong.  Often people who don’t have time to test will waste hours debugging code that they are desperately trying to force into production.  This code ends up being brittle and costly to produce anyway.  Corners cut on testing ultimately translate into a more costly investment in debugging and code fixes.  When recently confronted with a peer who claimed that they didn’t have time to test, I angrily responded that I spent two days trying to get code working that was breaking due to a careless mistake in their code (which I then had to help debug).  They didn’t have time not to test!

Granted, learning to test adequately is not a trivial task and can sometimes take years to really get right.  This effort (and investment) is well worth the trouble as it will not only produce better code, but will most often transform how the programmer sees code.  Although I sometimes have to work pretty hard to “tame” legacy code, the investment rarely proves to be wasteful…rather it saves time and money.  Testable code is maintainable code.  Maintainable code is cheaper code.  As developer teams become better at testing they also become better at producing quality code.

Ultimately, I don’t believe that anyone doesn’t have time to not test.  Degrees of coverage may vary due to time constraints, but the value of tests remain constant regardless of deadlines.  A simple test for a possible exceptional case can avoid days of fretting over a rare NullPointerException in production.  Tests have saved me countless hours of time while writing C, C#, Java, JavaScript, and LISP code.  Tests have girded me with incredible confidence in the code I was delivering (within reason, of course…lol).  Everyone should have time to test (the complex code at the least).

After about over a decade of coding professionally I’ve settled on the credo: “No tests, no trust”.

Related Articles:

    Post Footer automatically generated by Add Post Footer Plugin for wordpress.

    About Joshua Lockwood

    I code stuff and people pay me for it.
    This entry was posted in Best Practices, Testing. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

    11 Responses to "I don’t have time to test!"

    1. Dan says:

      Any tips on decreasing that 4 year marker timescale?

    2. Dave says:

      I’ve not got time to read all that!

    3. Jarod says:

      as Beck would say: the “No time for testing” death spiral.

      “The more stress you feel, the less testing you do. The less testing you do, the more errors you will make. The more errors you make, the more stress you feel.

      Rinse and repeat”

      http://books.google.com/books?id=gFgnde_vwMAC&pg=PA124&lpg=PA124&dq=%22no+time+for+testing+death+spiral%22&source=bl&ots=enGxrqVnuK&sig=jeFZ-rAgyVWbvdGPgXJDJvWQR-E&hl=en&ei=QrDkSYOpKJ6EtAODs6S9CQ&sa=X&oi=book_result&ct=result&resnum=1#PPA124,M1

    4. Chris Missal says:

      I like to respond to that with:

      “You’re already testing with the debugger, TestPage1.aspx, or whatever… Just save that code and automate it!”

      Also, I’m going to disagree when you say “(the complex code at the least)”. I find that even very simple code can benefit from tests. Small code can sometimes cause big problems when overlooked.

    5. jlockwood says:

      @Dan

      The key is to commit to ‘wasting’ a little time testing each day (commit is the key word here). As time progresses you will become more comfortable and proficient at testing. Start with simple tests using an easy-to-use test framework like NUnit. Grab a tutorial for the framework and write tests based on what you learn. Overtime you’ll learn how to get more complex code under test.

      I’d say the key is not to get overwhelmed (if you are working on a large legacy system) and learn as you go along. If I had junit when I first started programming I’m pretty sure I would have been ‘test infected’ within my first year. The tools available these days are really nice.

      What are you doing now Dan?

    6. jlockwood says:

      @Chris

      I said “complex code at the least” because if I’m truly pressed for time I have to prioritize where I spend the most testing effort. I’m currently working on a big legacy system and could probably do nothing but write tests for 2 years and not have the coverage I’d like. With this system, I tend to test the most breakable and complex pieces first (mainly so that I’m in a position to safely refactor…I’ll want to simplify that code ASAP). Testing POJOs, simple DAOs and whatnot is way lower on my priority list.

      I tend to use TDD for new code, so it’s not an issue in that respect.

    7. jlockwood says:

      @Jarod Awesome reference!

    8. Shantanu says:

      As Neal Ford says, testing is only a by product of TDD. The main intention of TDD is to get your design right even before you write code.

      http://www.sda-india.com/conferences/2009/JAX-INDIA/slides/Neal_Ford/slides.pdf?

    9. Cannot agree more, small tests for domain layer code are saving my life…

    10. Mark says:

      As a new convert to tdd or at least automated testing, one of the main drawbacks was getting the framework and config write, and jumping the first hurdle or tests.

      But after you have done it once, even if you don’t do TDD, automated testing is a god send.

    Leave a Reply

    Your email address will not be published. Required fields are marked *

    *

    You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>