Skip to content

Why do we still question why we write tests?

I enjoy reading blog comments. In most cases, I enjoy it more than the actual blog article itself. I also really enjoy blog posts about improving process and becoming more productive.

Often, I’ll read a article about testing, and will casually skip over comments about “Why should I TDD? There is no evidence that it actually does something?”. I also skip comments with name calling and the like. Unfortunately, there is one type of comment that I can’t skip over: If you question why we are testing, then we (as developers) have failed.

This one comment in particular went something like, “when things change and propagate up the code base, doesn’t having unit tests mean twice the work?”. I only have one answer for a question like that. YES! It does mean twice the work. The alternative is worse. The alternative is not know how much work will be needed. The best case scenario that I can think of would put it some higher multiple than two.

This is just something to think about the next time you think that skipping that one small unit test.

Posted in Smarticus Says.

Tagged with .

6 comments

By bryanl – May 12, 2011

  • Ryan Davis

    Just think about how much faster the development of boeing’s jets could have been if they didn’t have any redundancy built in!

  • http://jackdempsey.me Jack Dempsey

    Maybe it’s not the Why that I’d like to debate, but I sure wish people thought more about the When and the How. I’d say Why as well, but leave that aside for now.

    I’m currently suffering from a lack of tests in some of my code. I hate it; I hate the feeling of “deploy and pray” and all those negatives that we abolish by writing good, thoughtful tests.

    I also hate writing a ton of tests and code and then realizing that a fundamental decision was wrong, or that the code is not needed, or we’re going in a different direction, etc. I’ve seen sooo much waste related to an overabundance of tests, duplicated tests, slow running and legacy tests…it can get painful.

    Maybe I’d like to see more advocacy of spikes, or maybe even just people saying “I wouldn’t write a test in this situation and it’s ok for this reason”. I believe strongly that those situations exist, even though it feels almost as if I should be whispering that.

    I’m totally with you on the “why do we still question”, but maybe in more of a “why do we not ask the right questions and at the right times” sort of way.

    We all know Why we do…let’s make sure we continue to think about When, How, and just why the Why is in fact making things better at this time.

    Apologies for a bit of incoherency, allergies kicking my butt today and brain foggy, but I wanted to at least try and get this out. Hope you’re well man!

  • http://smartic.us bryanl

    I can offer a few pieces of advice. Hopefully they’ll put you on a better track:

    1. Stop trying to be so smart. Developers are smart people. (I’m sure this can be debated). At least they think they are smart. Have you noticed that you write code better now than when you started? It isn’t because you are any smarter. It is because you have learned how to be a better developer. The first thing you want to do is learn to trust your method (whatever it may be). Leaving being smart for watching Jeopardy.

    2. If you really want to go the TDD route, before you start coding, you have to ask yourself what you are doing. Then you need to break that down into steps. Then you need to figure out the first single behavior your object needs to be expressed. Write a spec/test that verifies that behavior, make the spec/test/pass, refactor what you’ve created to get rid of unneeded code, and repeat. At the most fundamental level, that is all that TDD is.

    3. If TDD is a bit overwhelming, there is another approach. Sit down and start typing. Just work on solving the problem that’s in front of you. The important thing is timebox yourself to 30 minutes or an hour. After you get done. Examine what you’ve made… then delete it. Now start over again. Now that you know how it works, TDD should be much easier for you.

    4. This isn’t easy. Most developers write shitty tests. They write tests that are then directly translated into their code. The only way to get better is to write a shit ton of tests yourself, and read lots of code. Try to have opinions about whether the tests you look at in other people’s code is good or not. Then look at your own. Are they better or are they worse? Can you learn anything?

    I have other pieces of advice too. Perhaps they’ll go in the next blog post. If you get really stuck, you have my IM. Use it. I’d be happy to help.

  • http://jackdempsey.me Jack Dempsey

    “

    1. Stop trying to be so smart. “

    Where is the ‘being so smart’ you’re referring to? Just a little unclear. Agree on trusting method.

    1. tdd route – “you have to ask yourself what you are doing. ” yep, and why. Are you trying to see what it’s like using a gem to connect to Amazon? Experiment with a new idea? Can you get done and evaluate its usefulness in 10 mins with no tests, vs an hour with? I think these are all good questions to ask and things to consider, and as you said next, spike–let’s say you figure out this is good stuff after 10 mins, you can now more effectively move forward, and if it sucks, you just saved 50. I think people just too often cargo cult testing and TDD and cargo culting anything to extreme is often a bad idea (yay for tautologies).

    2. Totally agree. I think there needs to be more emphasis on these types of statements. It’s not just enough to ‘test’. Tests can be just as shitty and buggy as your normal code.

    I think if people took the same pride in well written, well thought out tests as they do in application code, we’d all benefit.

  • Anonymous

    Code should work, and that is, to some extent, guaranteed by the tests.

    Whether the code will work in cases that are not included in the tests or code is written properly those are very different questions.

    TDD is great, it allows to do something that works in an agile way. But it promotes some bad practices when programmers only care about writing a code that passes some tests, the code may not be maintainable or upgradeable or readable at all. And that is a big problem.

    In short, what I want to point is: TDD is great, tests are useful, but they are not the Holy Grail, and other aspects of the code have to be kept in mind by those doing TDD.

    Sometimes (usually) code that doesn’t work but can be fixed is better than code that does work but cannot be adapted (to a different environment, requisites or whatever).

  • http://twitter.com/Pen_Bird Phlip

    Such redundancy would be worthless if the multiple parts were _exactly_ the same. Then they’d all trivially fail at the same time. If a project has a requirement for redundant parts, as failsafes, then the parts should perforce be different. Hence they are still DRY. Does that answer your question, masquerading as snark?

« »