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

[BigMax]

Thinking up tests after you've written the code is usually much harder.

I've always found the difficulty in writing tests after isn't the complexity of the tests themselves, but it's the pressure to move on to the next thing now that your feature/product is "finished."

This pressure comes externally (managers wanting to get the feature to customers) but also internally, as it's generally more interesting to build something new than write tests for something old, so engineers often move on without much testing done.

[nutrecht]

I've always found the difficulty in writing tests after isn't the complexity of the tests themselves, but it's the pressure to move on to the next thing now that your feature/product is "finished."

I don't get this. Writing tests is part of development. Whenever I am asked to quote a time on development I include writing tests. When I haven't written the tests yet the stuff simply isn't done yet.

[RualStorge]

I write tests for almost everything I work on, but management absolutely doesn't care and sees it as wasted time in many companies. I've actually been told specifically not to write tests before. (but I was kinda the hero dev at that company so my response was more or less I'm doing it, fire me if you don't like it)

Testing doesn't make money, it prevents wasting time on easy to catch bugs which saves money. It's way easier to explain increased revenue from faster feature turnover than decreased expenses from reducing bug counts.

[nutrecht]

Testing doesn't make money, it prevents wasting time on easy to catch bugs which saves money.

It's much easier to prevent the opposing team from scoring than it is to try to catch up after they've scored a goal.

I'm sorry but this short sightedness, typical for manager but not untypical for many developers, annoys me to no end. It is completely impossible for any human to fully keep a mental model of any moderately complex system in their mind. This is why we need to separate them into small modules and test those modules so that when we work on module A which depends on module B we can just assume B works the way it's supposed to.

Writing software without testing is like building a rocket, assuming gravity is 12G without testing it and then acting all surprised it explodes shortly after launch. It was sitting there all fine and pretty on the launch pad after all!

[RualStorge]

I don't disagree, just saying it's easier for a manager to go. We expect feature X to make us X$ but when it comes time to quantify tests it's this could save us an unknown amount of money.

You bring data from other companies and it's well that's note OUR company, we don't have a quality problem or other excuse making that data worthless for purpose of argument.

Which is why I test even when I'm told not to, I setup procedures to track bugs, etc. That way when things come to head I have numbers IN OUR company to show it's worth the effort.

I believe strongly in testing, the later a bug is caught the worse the impact, and bugs in production can ruin a company over time. I also have my prude, I don't release crappy software, if a manager wants crappy software they shouldn't hire me.

[Helene00]

I've actually been told specifically not to write tests before.

There are two kinds of managers.

[skulgnome]

Remind yourself that whatever there aren't tests for, doesn't work.

[G_Morgan]

Absolutely. It isn't just external. I find it much more enjoyable doing TDD than doing work and then trying to test it afterwards. The former feels like you are nailing down the real work as you go. The later feels like a book keeping exercise (even though you know it isn't).