Unlike, it seems, everybody else I find unit tests to have very little use, but hey if you want them do so.<p>TDD on the other hand is both an unprofessional waste of time (write code that you know isn't going to work just to make a test that you know isn't comprehensive enough pass? Really?), and an unprofessional way to structure your design - instead of a bunch of well behaved classes that abstracts and neatly encapsulate their behavior, you have to insert hooks so that you can inject your mocks.<p>At the end of the day, you end up testing software and find some, but far from all, of your bugs.<p>If you are concerned about software quality, great - write better code, do root cause analysis, but most of all: use a language with a good static type system.
"It will make our work so much more efficient"<p>The common complaints he lists at the start and acknowledge actually all boil down to the fact that unit tests do not <i>always</i> make work more efficient. It's a tool in the toolbox. Sometimes they are great for your project. Sometimes they are a waste of time. It's still not magic pixie dust.<p>In my current project we have a test suite for our public webservice APIs and various clients that interface against those. Those tests are invaluable. For other parts of the project unittests don't make sense, so we don't have them, since making them would be a colossal waste of time.<p>So yes, you still need to defend unit tests, just like you need to defend <i>every other</i> choice you make during development. No specific tech gets carte blanche.
From a bit philosophical point of view a program is the specification of what the computer should do. Unit tests and type annotations both are some kind of checksums.<p>Generally I am for brevity: the program should be short. So I prefer that the 'checksum' also should be short. Unit testing is a really elegant and good tool if you can test a quite big chunk of functionality with a short test. If the test is for example longer than the tested functionality then its value is more controversial. Ok, for extremely important code, like the control of an airplane, put there as much redundancy in the checksum as you think is needed. But otherwise, it can be questionable.<p>The issue is quite similar with static typing. I am a static typing fan, but dynamic language guys always complain that you have to type too much in static languages. And they are right to some extent, although better static languages have good type inference, so it is not that big of an issue.
In fact I don't really understand dynamic language guys. They always state that they like terse code, but with modern statically typed languages like Scala you really don't have to type much more than in dynamic languages. The difference is negligible compared to that those same guys are usually unit testing fans and their unit tests sometimes really make the code base significantly bigger.<p>TL;DR;: I value terseness, and I prefer to use both static typing and unit tests only if it does not increase the code size significantly.
As both a TDD and HN fan I'm really quite surprised to hear the anti TDD rhetoric here. To the detractors here are some honest questions:<p>1) How many projects have you worked on that were 100% test driven and written outside-in?<p>2) Do you have the knowledge to test any code, regardless of web APIs, filesystem etc.?<p>3) When you deploy an app without 100% coverage how can you be confident that there are no regressions?<p>4) When you add new functionality are you comfortable changing the existing code or do you try to leave it alone and build on top of it?
I also can not believe how hard it is to convince people of the advantages of testing.<p>I often see stories that are not accepted multiple times simply because the product owner has changed the intent of the original story. Tests really help to define what it is that the product owner wants before a line of code is even written.<p>In the bigger picture, how much "more time" does it really take?<p>Dumb story, but my dad taught me how to do word working: making European Cabinets. So many times he would say "Measure twice, cut once." This, in some convoluted way, could apply to software engineering.
Again with the "professional" slander, as with the TDD article…<p>I hereby declare that anyone who doesn't follow Jackson Structured Programming is a two-bit script kiddy!
I wonder if the split between pro/anti unit testing comes from folks in traditional developer positions vs startups (since there is a decent mix of both here).<p>As a pure developer working on an established codebase, the benefits of automated testing are quite clear, especially if you have paying customers and the cost of failure is high.<p>But as a startup, every extra line of test code you write slows you down from launching, and the most important thing at this point is launching and figuring out whether you actually have a market for your product.<p>After all, what's the point of having 100% test coverage for a product that no one wants to use?<p>It's also entirely likely that you're going to end up throwing large sections of your codebase out as you pivot towards something else.<p>Here's the way I see it:<p>It's rather pointless to have 100% test coverage of a product that no one is using, but it's also dangerous to have 0% coverage of a product with live, paying customers.<p>Intelligent developers will have the find the right balance between the two (as it shifts over time).
Hi all,<p>I'm the author of the blog post. I'm very glad that it has gained already so much opinions and feedback.<p>As user ollysb, I'm quite surprised to notice that there seems to be more against the post than for it. And that was one of the reasons why I actually wrote it: You are smart guys, please proof me wrong about unit tests. I can only find good things in unit testing, so it seems that I have not fully thought it through.<p>ps. Did the post have "inflammatory tone"? It was definitely not my intention. Sorry if it did. I have done computer programming for living only just about 10 years and I am definitely not a professional in it yet. Which parts made it sound cocky? I would love to hear feedback for that too improve my writing.
Importance of unit tests varies with the projected lifetime of the software you're writing. If you're writing libraries or system services, then unit testing is smart, as those are bound to live on for many years. Simple end-user applications might be a different case.<p>On the systems side (in this case, a PHP framework), I've found that once test coverage passes 70% you can make optimizations and refactor the code without having to actually run it - the tests will tell whether the changes you did still maintain API stability.
There's a bit of a solution to this out there: if you are a developer who really cares about unit tests, make sure to ask any prospective employers how they feel about them during the interview process.
More time spent writing unit tests does not imply the product will be better for it.<p><a href="http://news.ycombinator.com/item?id=1846841" rel="nofollow">http://news.ycombinator.com/item?id=1846841</a>
Completely unrelated, but just this made my day. After upvoting:<p>Pledging for unit tests (madebymonsieur.com)
NaN points by koski 1 hour ago | 11 comments