> we have a /slightly/ better ratio than 1 test per 100 SLOC, etc.

Has TDD really resulted in this becoming a status symbol? :P

Problem is that all status symbols in the programming world are meaningless, so in the absence of any useful metrics, we latch onto useless ones.

Tests/LOC at least measures something, even if it is imperfect. It's probably better than measuring LOC themselves, which are often a long term cost for the company, not a benefit.

but, Tests/LLOC seems to state even less than LLOC. LLOC gives an indication of the complexity of the application (or a component).

All Tests/LLOC seems to state is that some lines of code exist and potentially, some test cases are testing them.

This is why code coverage numbers are a much better metric.

It's also a measure of test granularity, i.e. for a module of given complexity, how many test cases cover it?

We can see what it measures. I'm just saying that it's a pretty nebulous metric when used out of context. Taking 2 numbers and condensing them into 1 (à la Megapixels) is an exercise in marketing.

Wow, I got blasted on this comment. So, there was a reason why I didn't start spouting our exact LOT/LOC ratio: I have no idea what it is. No one at our office does. That's not the important part. My point is that, on average, one test per 100 LOC is almost definitely not covering much of the logic. I mean... if you have one happy-path test and one expected failing test per block of code, you have one testing context per 200 lines. Two hundred lines!

I'm not understanding this comment. Which part of this post made you think that your decision was great? The fact that you started a software firm? the fact that no one has an office at your firm?

The fact that there is a culture; not cabins,

Can't tell if trolling or not...