in reply to Re: Test Driven Development, for software and for pancakes
in thread Test Driven Development, for software and for pancakes

For me, the first point above is the most important: TDD improves interfaces and design.

I agree with this.

What I find disconcerting is that many when they hear TDD and dismiss it never get around to writing proper tests at all. To me, that's an absolute shame (s/ (shame)/insert_bad_word $1/). Not following TDD != don't write any tests.

For example, I know of a company with a very large software suite, and it pisses me off to no end that bugs are frequently found that should have easily been caught if even a few basic tests had of been written. I mean, you have a feature in your software for many years then suddenly it breaks when one is doing a deployment? Give me a break.

I do TDD most of the time, but not all of the time. That doesn't mean one shouldn't write tests at all... it just means its much more unlikely that anyone will get around to it going forward. Personally, 100% coverage is my objective, from several different angles. Either specific existing tests (possibly having been updated or added to) are run before a commit, or if required the whole suite passes first.

Whether one does TDD or not, never neglect a good quality test suite. It doesn't matter if the project is late. On a complex project, would you rather have data inconsistencies in client data down the road because of your neglect, or have the project behind a couple weeks up front because you're validating your code before or as you write it?

update: This kind of sounded like I'm reflecting on you, eyepopslikeamosquito, but it surely wasn't. It's a global thing ;)

Replies are listed 'Best First'.
Re^3: Test Driven Development, for software and for pancakes
by stevieb (Canon) on Jul 23, 2017 at 23:14 UTC

    I am going to provide a real-world example of why tests are very important, based on a situation I ran into today.

    I wanted to make some changes to my XS-based Bit::Manip distribution. One of my goals was to replace calls to stdint.h's pow() function with bit shift operations instead, to remove the reliance on the external library.

    With my full test suite in place, I could freely replace things like:

    #define MULT 2
return ((int)pow(MULT, bits) - 1) << lsb;

    [download]

    With:

    return ((1 << bits) - 1) << lsb;

    [download]

    ...and not have to worry about a thing, because all I had to do was make the change, run the tests, and on fail, go back to the math. Once all tests passed, I knew I was good.

    Without a test suite, how would I ever know if I'm 100% accurate in my modification? I wouldn't be. Because all of my subs are covered entirely, I know that one change there didn't break anything within the sub its defined in, nor does the change break anything far away either.

[reply]
[d/l]
[select]

      Hi there. Unwittingly, you have provided perhaps the perfect counter-example to TDD.

      Similar to how one cannot prove non-existence, one also cannot anticipate the unforeseeable. In other words, tests may guard against regressions, but they cannot save you from bugs.

      In C, bitwise shifts by less than operand width, are allowed. Given 32-bit unsigned int, a shift by 32 invokes undefined behavior. And in particular, on x86 this shift is equivalent to a NOP.

      print bit_mask(32, 0);

      But don't feel too bad about it; similar shift-mask bugs have occurred in security-critical contexts before...

[reply]
[d/l]
[select]

In Section Meditations