Why To Write Tests For Your Code

The universe tends towards maximum irony, and you are seriously underestimating that maximum. Even with 100% test coverage, fixing something 5 minutes before launch is an awful idea. Either delay the launch, or accept that the bug is small enough to not matter.

Laziness, ignorance, rapid prototyping, no budget, more important problems... all the obvious reasons. I can't think of any "good" reasons from an engineering perspective, only business.

Some of the blur is caused by different kinds of programmer experience. We have to work with the "art" and "creativity" variable here, along with "has seen a similar pattern before". The other problem is asking the right question: What kinds of testing can create a consistent and solid improvement in acquiring money (or some other important pointy-haired boss measurement) over a 10-year period of time?

There are things that can make us feel good, nice placebos. For example, 100% test coverage is known to not equate to good, working, maintainable code: you may be missing features or doing things completely wrong, but your tests validate that your wrong thing or lack of thing is working.

Is there a magic bullet? Probably not... but it is widely believed (and probably justifiably so) that automated testing helps somehow. People will expound on the benefits. Personally, I want numbers. I want to know the pain before the tests and the less pain afterward. I want to know confidently that the time spent writing tests as part of development is less than the time spent discovering and fixing problems. Note the careful wording there.

http://research.microsoft.com/en-us/news/features/nagappan-1...

What the research team found was that the TDD teams produced code that was 60 to 90 percent better in terms of defect density than non-TDD teams. They also discovered that TDD teams took longer to complete their projects—15 to 35 percent longer.

So, as with all classic engineering debates -- emacs vs vi, MySQL vs MongoDB, et cetera -- there is no definitive answer to the question should we write these tests or not? because it's an engineering tradeoff. Writing tests and then throwing them away is foolish: You wasted time. Not writing tests and then fixing 60-90% more bugs is foolish: Bug fixing is a waste of time, often wasting more time than it would have cost to avoid the bugs up-front, and risking breakages in the process.

Which waste of time is better for you? It depends on the business situation. There are situations in startups where it's not worth while to write tests. Indeed, there are situations where it is a mistake to write code at all: Use a big pile of post-it notes and a cheap outsourced worker to mock-up the system while you prove that you actually need it. Whereas once you've found your business plan the more typical mistake is to write too few tests, which is why there's a big popular movement that promotes writing lots of tests: There are more people with too little testing than people with too much testing.

You can write tests for the core algorithms and data structures but that is often only around 10%.

The best you might do would be to come up with examples of people who used unit testing and things came out beautifully because of it. Things rarely turn out that beautifully without testing, so it can be pretty convincing to anyone who has dealt with software development for any length of time.

You don't give reasons for using an ORM in your code, do you? You just do it as part of your development work. It's nothing that's being questioned by PHB's.

Writing tests is (or should be) part of your development work.

Make sure you include the time it takes to write the tests in your "time estimate".

If I am estimating how long the work will take, I am estimating how long it will take to get the functionality working correctly with X% confidence it works correctly when the product ships. Unless “X” is less than 50%, automated testing is part of writing the code, not a nice-to-have.

“Improving the quality of our code” does sound vague, kind of like arguing how many knots are permissible in a plank of wood destined or a kitchen floor. Instead, I would simply explain that these tests I write are part of writing the code, and to explain that if management want the code without the tests, they need to tell me in writing that they are ok with a confidence level hovering around 50%.

I am not kidding about this number. I may deliver code that appears to do what it is supposed to do, but my experience is that either it is broken in ways that a simple QA test doesn’t show, or somebody (somebody else or even me next week) is going to regress it between now and when the product ships. Automated tests give me the confidence that it works, works correctly, and will continue to work correctly.