1. 23

  2. 6

    I’m far from a great programmer so I find TDD to be very helpful.

    If I can’t write proper tests it helps me highlight that I don’t know enough about the problem I am trying to solve. I find this to be especially important when writing code specified by others (as opposed to writing some idea of my own).

    Also, I really, really, really hate re-work so having tests up front with known good and known bad inputs reduces risk that I secretly break code which I then have to go back and fix months later.

    Python and Go have decent support for my way of working but there are cases where I would prefer to write something in C (especially pledge() in OpenBSD is a huge draw) but don’t because I am not familiar with anything that makes TDD as easy in Python/Go.

    What are C’s answers to, say, py-nosetest or go test?

    1. 1

      After reading the OP, I have been researching the same. What is a good tool that I can use in my systems projects in C. It may or may not support TDD style, but at least should enable me to want to write more tests fast.

      1. 1

        For c++ I’ve been using CATCH and I’m a big fan. It makes setting up tests almost as easy as for Python or Racket. I think it may work for C too.

    2. 6

      As someone who does not practice TDD, I did not find this post motivating to do so. His primary argument is that the person did not do TDD long enough, which is an argument that can be repeated forever. “It works, you just have to work at it longer”. The rest of it is, I found, rather hand wavy. Most of it focuses on the process rather than the end result. The main argument I have against TDD is that if I come out with code that is testable and tested, does it matter how I got there? This post makes a big deal out of the process and never stops to discuss whether or not the original poster (Sommerville, I think?) actually needed TDD to accomplish what he wanted. I haven’t read the original post so I don’t know the tone or what it was trying to do, but I find that is a common mindset among TDD advocates I’ve heard of: It’s all about the process not the end result. And, indeed, how could it be about anything else with a name like Test Driven Development.

      For what it’s worth, I think TDD is valuable as a learning experience to understand how to write code that is testable. But that only encompasses a handful of techniques that you can learn pretty easily and repeat for any new codebase. After you’ve learned that, you can expand to other ways of design code. I, personally, prefer to focus on building the API, and by that I mean the actual interface, not the implementation, until I feel comfortable, then going from there. But it depends on what you’re after and what you are working on.

      1. 9

        As someone who does not practice TDD, I did not find this post motivating to do so.

        As someone who discovered TDD 11 years ago and still uses it I agree: I find Bob’s zeal and condescending tone trite and off-putting. Mark Twain described people thus afflicted when he said “To a man with a hammer, everything looks like a nail.”

        There are other ways of arriving at well-designed, well-tested code than TDD. I strive to have more than a hammer in my toolbox. In the last few years I’ve taken up Clojure (though just as a hobby so far) and enjoy REPL-driven development a lot.

        1. 1

          The trick with testing in a REPL is that it is a little clunky to then translate that over to a repeatable test file.

          Actually…that’d be kind of a cool add-on to bodge onto iex or irb or even node -i. Something like:

          > TestSession.startSetupForTest( test_name )
          > ...user runs several setup commands
          > TestSession.startTest
          > ...user runs various test commands...
          > TestSession.writeTestFile
          > ...etc...