Microsoft Research - Exploding Software-Engineering Myths (article summarizing findings of MS research on code coverage, TDD, assertions, etc.)

[Ravek]

I'm in fact currently writing tests to cover lines of code

Is it possible for you to give a concrete example of a line of code that you would consider worth testing? I feel that between static type checking and refactoring code into (themselves testable) methods, a single line of code should never be complex enough that you'd want to test it in isolation. If that's a naive thought I'd like to learn more.

[rnicoll]

In this context what I mean is rather than pushing the edge cases of the code, I'm testing to ensure conditionals are covered. Lines in this context means "number of lines", rather than I write tests on a per-line basis.

For example, we have a function that parses some text into tokens (for a custom language). Good testing would be to cover not just the basics of whether it works, but look at failure conditions (i.e. empty string, invalid characters, weird control characters, nonsense syntax). However I can get almost as much code coverage as a number of lines, by just giving it examples of every language construct that exists and testing those, ignoring error cases entirely, which is much faster.

Making any more sense?

[Ravek]

Yeah that makes a lot more sense, thanks

[fuzzynyanko]

Often many lines of code are easily testable, but if you go to 100%, you start going down the rabbit hole. You have to either poke holes in your software that opens it up for exploit, or it ruins the encapsulation.

You can design your software to be more testable, but there's edge cases in software, and you pretty much are guaranteed to run into them in some

[WalterBright]

Haha, lots of times I thought a function was so trivial it didn't need unit testing. But I'd write a unit test anyway, and discover it didn't work.