Close
Glad You're Ready. Let's Get Started!

Let us know how we can contact you.

Thank you!

We'll respond shortly.

LABS
Silly gents, it is doing a good job (7)

I recently published the article There is no Agile, in which I stated that the principles of ‘Agile’ are nothing more than “a collection of good ideas, based on years of collective experience, for improving how we do our jobs.” As an example, consider testing. Thorough testing is a ubiquitous principle of ‘Agile;’ thus, by logical extension, writing tests is a fundamentally important part of writing software well.

In short, if you write software, and you’re not writing tests, then you’re not doing your job.

I don’t mean not doing your job like a waiter who doesn’t take your order quickly enough; I mean not doing your job like a surgeon who operates without washing his or her hands. As in completely unacceptable performance.

As a corollary, if you’re not writing high quality tests, then you’re doing your job poorly. If you don’t achieve appropriate test coverage then you’re doing your job poorly. If you focus excessively on verification, and ignore the other benefits that tests can provide, then you’re doing your job poorly.

Several authors and accomplished software writers have cataloged the ways that thorough testing will lead to better design, the ability to refactor, improved resilience in the face of changing requirements, fewer defects, etc. In order to justify not writing tests the costs would have to overshadow these advantages.

I can’t think of a valid argument for not writing tests, although I’ve heard many attempts:

  • “It takes too long.” Consider that around 75% of the time spent on average software projects is bug-fixing and maintenance.
  • “This code won’t change.” It will. And it should.
  • “I know my code works.” Will it work with my code? With the code you write six months from now? When the functionality changes? (see above)
  • “It’s a prototype.” Fine. Throw it out when you’re done and use what you learned to write tested code.
  • “It’s not testable.” Unlikely. Far more likely you simply haven’t though of a way to test it.
  • “That’s what QA is for.” This statement shows so little respect for the people you presumably work with it warrants no response.
  • “I can’t be bothered.” McDonald’s is hiring.

In my experience, people who denounce the value of tests are nearly always people with little experience writing tested code. It’s time we stop allowing ourselves to determine how we do our job based on who has the biggest ego, who can shout the loudest, or who is the most resistant to change.

All this leads to the question that every single person reading this should be asking: writing high quality tests can be very difficult; how do we teach that?

Comments
  1. No, my main criticisms.

    * Takes focus away from code clarity and simplicity.
    * The idea that “the test explains the function” is very dangerous. Your code should be so clear that it doesn’t require reading the tests to gain understanding.
    * The idea that “tests protects bad programming.” If you have bad programmers on your team, then yes, please test. However, I don’t accept patches or work with people that produce code that isn’t clear, concise, and bug-obvious.
    * Takes the emphasis away from writing bug-obvious code. That is, you should program in such a way that bugs are obvious. It is possible! Lurking bugs are rarely caught by testing. Writing bug-obvious code is nearly the same as writing the tests
    * False sense of security. Instead of doing things to fight bugs in your primary code, you trust the tests. This de-emphases careful thought and QA.
    * Your tests are just as likely to introduce bugs as your code. You might even *test* for the wrong thing and produce code that is flawed because of a broken test.

  2. Adam Milligan says:

    Hampton, I think you need to take note of my comment regarding excessive focus on tests as verification.

    Out of curiosity, how much time have you spent test-driving?

  3. Dmitry says:

    “All this leads to the question that every single person reading this should be asking: writing high quality tests can be very difficult; how do we teach that?”

    Hm. Actually, this leads to another question – if writing high quality tests is very difficult, is it more or less difficult then writing high quality software in the first place?

    And if the two are comparable, perhaps this leads to yet another question – does the fact that tdd leads to high-quality software, mean that it is the only possible method that does so?

    Shouldn’t the real issue be finding the right mix of methods that gives the best cost-benefit ratio?

  4. Clarence Odbody says:

    If writing good tests is difficult, but the the most well tested programs tend to be better, then perhaps it is a self-selecting group. Those capable of producing good tests are also capable of producing good code.

  5. Adam Milligan says:

    Clarence, your point is exactly correct, although I suspect not for the reasons you intended. Good developers are those who can write good code, but who recognize that they can write better code with techniques like TDD. They have the humility to incorporate new ideas into the way they work, and embrace the learning curve that comes with them.

  6. Tom Moertel says:

    > In short, if you write software, and you’re not writing tests, then you’re not doing your job.

    Likewise, if you write software, and you’re not doing *more* than testing, you’re not doing your job.

    The goal of good programmers is not to “test” but to work efficiently and be confident that their code is clear and correct. Testing certainly contributes to that goal, perhaps more so than any other single programming practice, but that doesn’t mean we should emphasize testing so much that it becomes “the” goal. Good programmers also need to understand the limitations of testing and learn how to supplement it.

    > All this leads to the question that every single person reading this should be asking: writing high quality tests can be very difficult; how do we teach that?

    Agreed. And when teaching about testing, we ought to explain what testing is *not* good at, too.

    Cheers,
    Tom

  7. Adam Milligan says:

    Tom, you’re quite right. I would never advocate blindly following a set of rules or practices, whether that be testing, XP, an SDLC, whatever.

    However, the problem we have is that so many people are doing so much *less* than testing. Teaching people to test effectively is a small step toward teaching people to write code effectively. But, it is a step.

Post a Comment

Your Information (Name required. Email address will not be displayed with comment.)

* Copy This Password *

* Type Or Paste Password Here *