Why To Write Tests For Your Code
masternerd.lucianocheng.com
Why To Write Tests For Your Code
1–10 of 32 posts
Re: Why To Write Tests For Your Code
#2There are obviously many reasons, but to add a couple;
Fight regression
You don't want to fix the same bug several times, do you? When a bug is found, I first write a test to repeat the bug. Then I fix the code. Now every time I want to release a new version, that particular bug is tested yet again.
The 'quick fix' 5 minutes before launch
You're approaching deadline, everything is looking fine. Then, just before launch, a small bug or a tiny new feature has to be added. You can't imagine that would have side effects, can you? Well, that one bit of code, a small module that 'never changes', which you haven't looked at for 12+ months, reacts badly to this change. With good tests in place you catch this before you hit production problems.
Re: Why To Write Tests For Your Code
#3I am relatively new to HN and have _read about_ but not _seen_ an anti-testing mindset around here. I imagine this article will stir that debate if it exists.
Can anyone tell me why they would not want to write tests? I have no biases here.
Re: Why To Write Tests For Your Code
#4I'd love to see an article on unit testing that gives reasons they add business value, so hackers like us can convince pointy headed bosses that we should be allowed the budget to write them.
"Improving the quality of our software" is the one I tend to use, but it's so vague. How will unit testing convert into cold, hard cash is what upper management want to know.
Re: Why To Write Tests For Your Code
#5More:
Make refactoring easier - I quite often write tests for legacy code if I'm going to refactor it. It's the only way I can know it's still doing the same thing. Sadly, this sometimes means doing some blind (test-less) refactoring to make testing possible, but that's sometimes unavoidable... And still far better than doing the whole thing blind.
Have more confidence - I use to dread the day we pushed things live. I would actually cringe while it happened, and just wait for the shit to the fan. The more tests I have, the less I cringe and the more I enjoy the releasing of new, better code.
Re: Why To Write Tests For Your Code
#6I am relatively new to HN and have _read about_ but not _seen_ an anti-testing mindset around here. I imagine this article will stir that debate if it exists. Can anyone tell me why they would not want to write tests? I have no biases here.
Can anyone tell me why they would not want to write tests?
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.
Re: Why To Write Tests For Your Code
#7I'd love to see an article on unit testing that gives reasons they add business value, so hackers like us can convince pointy headed bosses that we should be allowed the budget to write them. "Improving the quality of our software" is the one I tend to use, but it's so vague. How will unit testing convert into cold, hard cash is what upper management want to know.
Sadly, like marketing, it's really hard to give definites with testing. Or any other good programming practice, for that matter.
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.
Re: Why To Write Tests For Your Code
#8I am relatively new to HN and have _read about_ but not _seen_ an anti-testing mindset around here. I imagine this article will stir that debate if it exists. Can anyone tell me why they would not want to write tests? I have no biases here.
Can anyone tell me why they would not want to write tests? 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.
Rapid prototyping is the best anti-testing reason I've heard yet. I even halfway agree with it.
But in my experience, even prototypes can benefit from it.
For me, testing actually makes the whole thing go faster. I spend less time worrying and more time developing, because I have the confidence that the rest of my code works exactly like I want it to.
Re: Why To Write Tests For Your Code
#9I am relatively new to HN and have _read about_ but not _seen_ an anti-testing mindset around here. I imagine this article will stir that debate if it exists. Can anyone tell me why they would not want to write tests? I have no biases here.
I do not have a solid stance, but I am inconsistent on writing tests. I like to differentiate between the notions of hand-testing code and automated-testing code. I firmly believe code written should be verified somehow. I have not totally bought into writing tests. Right now, there is a lot of snake oil about what is better than what, and I would like to see good scientific studies that point in solid directions.
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.
Re: Why To Write Tests For Your Code
#10I am relatively new to HN and have _read about_ but not _seen_ an anti-testing mindset around here. I imagine this article will stir that debate if it exists. Can anyone tell me why they would not want to write tests? I have no biases here.
There was a good article that turned up for me just the other day (although it turns out to be from 2009) that captures the source of the problem:
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.