I 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? I have no biases here.
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.
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.
What I really like is Selenium test that work like manual testing and I thus feel they just automate something I would need to do in any case.
At an old job, we had what was called "random testing". This was a time to relax and take a few hours to pound at the application with whatever we could think of. With luck, someone would go ahead and attempt to automate those tests. One of our favorite "random" tests was to start some complicated process and then shake the window all around the screen to see if it would crash -- sometimes it did! It forces people to rethink their threading approaches. Another fun trick is closing an app mid-processing; does it exit gracefully?
You can write tests for the core algorithms and data structures but that is often only around 10%.
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.
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.
It irks me when clients tell me how I should do the thing they're paying me to do. It seems counterproductive and is insulting.
It's a little bit like if you eat at a restaurant and you've got 20$. The cook could tell you there's something really good and way better at 50$.. but if you're happy with something less good at 15$, well, it's your body and your money. (I know that development is way different and in the long term tests will save money, but depending of the project, it's not always the case.)