If you are writing bad stateful code that has a lot of bugs and you are not smart enough to figure out how all the states interact, unit tests will help you a lot, but there are many other scenarios where unit testing is useful.

I would not say good code has few unit tests. I say arrogant code has few unit tests. If you write few unit tests, as the size of the codebase grows, you have increasingly less certainty about how any change to the existing codebase will affect other parts. When the codebase is small, this is not a problem. If you are very intelligent, the size of the codebase that you can manage in your head might be quite large. But you are just wasting mental capacity that might have been doing so many more interesting things if you didn't have to remember everything and could trust your unit tests to give you the information you need when you need it.

My biggest argument in favor of writing tests is to ensure my code doesn't break relative to other people's code. There are many times I've encountered an update to a ruby gem with no major or minor version change that has broken a, usually implied, contract with my code. I say implied, because duck typers, at least what I've seen in the ruby world, tend to be slack about formalizing interfaces. I write tests to protect against that sort of thing.

You don't, but once you discover it, you write a regression test to make sure it doesn't come back.

However, IANATDD, I am not a test-driven developer - I don't see any reason to be dogmatic, but I do think unit tests can be extremely valuable. So this answer might not be TDD-approved.

"You don't, but once you discover it, you write a regression test to make sure it doesn't come back."

Sure, that's SOP in any good dev. house that does testing. But you've failed to address a key weakness in TDD. The real question is how do you discover these sorts of defects given that a single developer writing in a TDD style is unlikely to do so? TDD is clearly not a cure all, and this is a major weakness of it. Other development techniques, many of which can complement TDD, such as formal code reviews and beta testing can do a better job of getting you to higher product quality than TDD alone.

Who said it was?

TDD is a design technique, not a testing technique.

TDD does force you to think about the interface of your abstraction, however. If it is painful to write (or maintain) the test, then that is a good indication that the abstraction is wrong or not being properly tested. Don't be afraid of deleting tests when they are not useful.

I often find that these unanticipated bugs are often due to incorrect abstractions. To fix it, create the correct abstraction and test it.

It is also simply faster to develop in larger projects than creating the state that would test your unit. For example, you could make a change, manually refresh the page, and debug or write the test and make it pass. You also get the benefit of regression testing.

Note that the narrower your unit, the less likely it will be useful for regression purposes.

I often find that when beginning a project, my units are smaller. As abstractions are built, the nonessential tests are deleted and future tests are built upon abstractions that I care about.

Indeed. Tests are a good idea in, say, Haskell, too.

Which is basically isomorphic to "good code is tight code". Duh.

Great point, my mistake. Title and headline updated (was: Good code has few unit tests). I really wish it were "duh", but measuring code quality by "unit tests per line" [1] is frighteningly common, and seductive in its simplicity and intuition.

1. Not necessarily directly. It might be in the form of "I'll add more unit tests to improve this code" (unit tests either cover an interface or they don't; going in to 'add more unit tests' to 'improve' code means you didn't define a clear enough interface to begin with). Or "our open source project has more unit tests than another" (but I won't point fingers).

The easiest way to bump your unit-tests-per-line metric is to delete lines of code. That's a positive thing, in my book.

If you're writing something simple, abstractions are probably just extra typing.

If you're building something that actually has multiple parts, those parts should be abstracted from each other.

Pulling an example out of thin air, shorter total code:

    var counter = 0;

    function foo() {
        log("Incremented");
        counter++;
    }

    function bar() {
        log("Incremented");
        counter++;
    }

    var counter = 0;
    
    function increment() {
        log("Incremented");
        counter++;
    }
    
    function foo() {
        increment();
    }

    function bar() {
        increment();
    }

    var Counter = (function ()
    {
        var counter = 0;

        return {
            increment : function() {
                log("Incremented");
                counter++;
            },
            current : function() {
                return counter;
            }
        };
    });

    function foo() {
        Counter.increment();
    }

    function bar() {
        Counter.increment();
    }

There are a surprisingly large number of programmers who learn "Oh yay, I can use abstractions to simplify this bit of code" and then turn that into "I think I'll make abstractions out of every bit of code". I was once one of them. In the process, they turn something that could've been a simple program, one that you could fit into your head, into an Enterprise Behemoth that you can't modify without implementing a half dozen interfaces and touching 30 files.

There's a cost to abstraction - it's (usually) extra code, it makes it harder to follow the logic of the program, and it makes your program less flexible in directions other than the intended use. So don't do it unless it actually gains you something in simpler code. Programs can become spaghetti-like through IFactoryFactories just as easily as they can become spaghetti-like through switch statements.

Also on Hacker News at the moment and fairly relevant:

http://coderoom.wordpress.com/2010/03/19/5-stages-of-program...

But. If you've defined nice clean interfaces, and a particular module has complex behavior that will have to evolve over time, then adding tests to certify that that behavior is correct shouldn't be too much of a chore -- and they save your bacon when you need to change it and track any regressions afterwards.

There are engineers who have a difficult time seeing things architecturally (for reasons ranging from ability to priorities). Razor sharp focus can produce a lot of unit tests while missing some refactoring that might have helped reduce the code base, and therefore the number of unit tests.

[Edited]

Sure, in an ideal world, everything is isolated by clean interfaces and encapsulation, but even in that ideal world, you still have a complex system that produces sometimes unexpected side effects (the emergent behavior of a software ecosystem).

  - One quality measure of an abstraction is the complexity
    ofits interface (ie API size).
  - Another measure is the amount of state the abstraction
    encapsulates.

  setParameterForNextCall(paramName, paramValue)
  call(functionName)

  Hence, good abstractions require few unit tests.

It's not at all a rebuttal of the article, though. The article points out that the number of unit tests a design requires is larger for more complicated designs. An interface like yours would require no fewer tests than another interface exposing the same functionality using conventional function calls.

I think, this approximation is at least not wrong. I don't know if the characterization is complete, but it looks right enough to fool me :)

However, I think the problem in the argumentation is that the author assumes that "use cases" is small. While I agree, that usually, the number of use cases for an API should be small, there certainly are abstractions with a lot of use cases which are good even though they require a lot of unit tests.

An example of such a big abstraction is something I developed in the recent university project. Basically, it is a domain specific language which is compiled into state machines on partial bit sequences (which are used to describe data deserializers). The major job of this abstraction can be described in a few formulas and the abstraction hides enough complexity to be worth it, but it requires quite a large number of unit tests due to the number of possible edge cases in the specification of the DSL. Thus, at least I'd consider it a good abstraction in spite of needing many unit tests.

Another way to get lean code is to use a proper, powerful, static type system. It enforces you to think about the code "skeleton" and the "tests" are done automatically by the type checker at each compile/load of the code. It also reduces the amount of testing needed: There is no way something different from an integer can be passed as a parameter, so you do not need to account for that.

My code does not use many Unit tests per se. But it does autogenerate a lot of test cases to check certain properties. Autogeneration is excellent at producing corner-cases, so if that is what you are after... I generally find this is a better use of my time as a programmer: Better spend some time developing the autogenerator than writing boring tests which my code for most part will pass in first attempt.

- My assertion is fundamentally flawed. - Even the line of code metric YOU come up with is fundamentally flawed.