When should you test?

When it provides value.

When is that?

It depends.

I wish it were simpler than “it depends” but this is unfortunately the truth.

Our profession isn’t surgery. It isn’t engineering. It isn’t painting. It isn’t sculpture. It isn’t carpentry. It isn’t woodworking. It isn’t construction. It isn’t house building. It isn’t architecture.

Our profession is all of these things and none of these things. It’s highly standardized and it’s highly customized. It’s rigid and it’s malleable. It requires creativity and it requires homogeny. It needs discipline and it needs chaos.

When we talk about professionalism in our industry, we first have to accept that we work in an extremely unique profession unlike any other out there. While we can take lessons from other industries, we can’t draw direct comparisons or conclusions.

Which is why in our profession, unlike so many others, the most appropriate (and admittedly most frustrating) answer for many questions is “it depends”.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Rant. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • If the answer were not “it depends”, then some bright spark would write the Application Generator 1.0 (which would never require a 1.1) that would take vague, ambiguous, even contradictory Word docs as input and spit out flawless secure scalable reliable and performant masterpieces of software. And we would all be out of work.

    It’s understandable that those on the business end would desire this but distressing when a technologist does.

    • Actually, software will likely be moving that direction. Perhaps still a long ways off from taking a word doc a business person can write and making working software. But software is going to evolve out of moving bits around and instead be about plumbing architecture and architects choosing levels of consistency. The demand for programmers won’t last a decade.

      • The death of programming has been 10 years out for at least 30 years now.

        Automation of practices like medicine is still in its infancy and the materials there change on a much slower schedule.

      • Programming will just move to another higher level of programming. But at the speed we are moving at the moment (not like object oriented or functional programming is something new), i think it will be much longer than 10 years

  • I couldn’t agree more.

  • I’m not sure if I agree with your answer. At times it works, but other times it doesn’t. It depends.

  • Philip Patterson

    How can one determine if the test is going to provide value? What measurements/metrics are tracked to determine this? Having seen most of the twitter rants yesterday and read the rebuttal posts today there seems to be a consensus from everyone that automated/unit tests are written “when they make sense” and “when they add value”.

    As you admit it’s very frustrating (and yet the most interesting part of being a solution provider today) that the answer is almost always “it depends”. If there isn’t a guideline I can use to determine “made sense” or a way to determine “value added” how can I evaluate what disciplines I should be doing as a software developer?

    We should be able to “stand on the shoulders of giants” and iterate and improve on previous work, but it sounds like there’s a consensus among almost everyone (at least anecdotal evidence anyway) that the biggest successes were born from throwing things at the wall and seeing what sticks.

    Consider me confused.

    • Our industry is part art and part science, this is where the art part comes in. At some point you just have to feel it. But if you are going to use Bob’s onion architecture as a guide, I’d say the farther out you are from the center / domain the less unit tests you tend to write.

  • You can build a billion dollar tech company on top of a backend system that has no tests (I would not advocate this but I have witnessed it). Eventually you will have to repay this debt if you want it to become a multi billion dollar company. So it depends on your definition of success.

  • Pingback: Unit testing rules of thumb()

  • I couldn’t agree more. Although “it depends” answer can get you frustrated, we are not building software for free. Someone is paying us and hope we will build something that adds business value. If “testing” does add business value (e.g., make design or documentation better) and reduce technical debt that we have to pay in the future, then we should always test.

  • Nathan Alden

    Who woulda thunk it! Everything old is new again, like calculating ROI for business activities!

  • kindohm

    I agree. Hard-core, high-coverage developers often say that writing tests is like wearing a seat belt. Would you drive a car without a seat belt? I think this is a terrible analogy. Testing isn’t an On or Off setting. Testing is more like wearing clothing. How much do you need to feel secure and/or protect yourself? Sometimes full body armor is required. Sometimes you just need jeans and a t-shirt. Sometimes running naked is ok.

    • I think not testing is more like driving a car blindfolded.

      AND without a seatbelt.

      • kindohm

        AND naked. Don’t forget naked.

  • Pingback: On Testing “Trivia Code” | ThoughtStream.new :derick_bailey()

  • Pingback: Stephen Balkum » Blog Archive » Some good reading()

  • I think that when there are problems, we should regularly check