I think we're going trough a thesis/anti-thesis cycle on tests - in the beginning, there was militant testing, 100% coverage, testing getters and setters etc (as well as more complex stuff, obviously). Then some people started coming around to the idea that there are actually large swathes of code that is simple enough that testing doesn't actually add much value especially compared to the effort of writing them, then that probably got a bit out of hand (to what you're referring to). Maybe the pendulum will swing back and we'll find a good heuristic for just how much testing is the right amount that isn't all or nothing?

It really also does depend on the language, or rather compiler. Specifically, tests are far more useful when static analysis doesn't exist.

Actually, in the beginning there was no testing and even justifying having automated test infrastructure or spending developer resources on unit tests was a hard sell to management (what are they paying that QA dept. for after all).

That bullet point surprised me. It comes right after "110K lines of code. A small number given what it does"; to me this reads like they didn't write tests because that would add complexity.

Can any SO devs give us more details on "not many tests"? Or how many bug reports get filed vs rate of change of software?

The things that obviously should have tests have tests. That means most of the things that touch money on our Careers product, and easily unit-testable features on the Core end (things with known inputs, e.g. flagging, our new top bar, etc), for most other things we just do a functionality test by hand and push it to our incubating site (formerly meta.stackoverflow, now meta.stackexchange).

You can look at reported bugs here: http://meta.stackexchange.com/questions/tagged/bug -- it's pretty frequent, at least one every couple of hours or so. The last commit in our "Tests" project was 14 days ago, where as the last commit in the code base was 4 minutes ago.

You should come down our way and do a tech talk about it.

If only for the wailing, gnashing of teeth and rending of garments.

Your people would literally murder me. Are you back from west coast / toronto?

I am, yeah. We do tech talks every Tuesday. I can promise free food that's not as good as yours.

Indeed, they seem to have achieved what many have said is literally not possible.

Also, some might remember when they had Uncle Bob on the podcast, the topic being unit testing, and iirc Bob preaching the gospel (~ you must write plentiful unit tests, or else) and Jeff and Joel (especially) more or less saying they don't quite get why.

(Am I remembering this story correctly? I swear that's how I remember it.)

It's been my experience that outside-in TDD seems like impossibly strict nonsense until you do it with someone who is good at it.

Then after a while it seems like an obvious way to work.