Is there anyone who have really invested time to learn proper unit testing and still thinks it is not one of the best programming inventions ever? Seriously, there are lots of naive posts lately on HN...
Would you by chance also be able to post us toward a blog post that gives some convincing examples of why unit tests / TDD are so great. I have read many advocacy posts that basically repeat the same mantra of how awesome it is, and I have read ones that use simplistic examples, but I honestly don't see how they can be so compelling. Or, to be more precise, how their value exceeds their cost.
Whereas the automated functional testing advocated by the OP makes a tremendous amount of sense to me intuitively.
I don't particularly find unit testing to be effective in programming. While naivety is often a dominating factor, it does not have to be so. First, you should note that you might have a different notion of proper than other people. Second, I don't think you can rank programming inventions. Undoubtly, unit testing is useful. The question one should ask is rather: is it effective? In this question we also lace in the factor of time spent.
Note that the most important programmer commodity is time. Time spent on a unit test means less time to write the program. Now, what ought to tip the scale is that later changes are easier to get right so in the long run, one should win time by writing down unit tests.
But personally, I think that there are other practices which are more effective: Static typing, assertions and automated test harnesses for the whole program. I'll choose to spend my time on these rather than unit testing.
I like _Working Effectively with Legacy Code_ by Michael Feathers. It's a collection of techniques for bootstrapping tests into an existing code base - carefully, incrementally restructuring the code to add enough tests to safely perform deeper structural changes. At the same time, it's ultimately a book about improving legacy codebases (testing is just a major technique), so it focuses on using testing when it's most useful.
(Also, maybe it's just me, but a book that starts from, "Help! I just inherited a C++ project with ten years of rot and half the comments are in Norwegian! How do I even start adding tests to this without breaking it further?" seems a bit more practical than one that starts by applying unit tests to example code designed for convenient testing. It's seldom that easy.)
It definitely helps to start with an environment where tests are easy to write, so that you can focus on the principles of testing without having to learn a lot of mechanics.
Python's built-in "unittest" module is an example of that. While it's not perfect, you can quickly form good habits by using it.
And it is not limited to Python. For instance, I've written unittest-compatible classes that basically run other programs as test cases. Either way, you're forced to think about things like "how do I automatically detect that this failed?" and "is the purpose of this test clear?".
I personally just sort of figured it out by doing BDD on a few small projects to get a feel for how things go. I'm not 100% "driven" now, but overall, it's pretty high. I tend to do Cucumber tests more than straight up unit testing, as I find them more valuble personally...
Doing is the best way to learn most things in the software world.
I think it depends a lot on context. There are some kinds of code where unit testing is just about the only way to test it at all and makes a huge amount of sense. There are other situations where unit testing verges on being a complete waste of time. One of those is that which the author describes, where you are writing what is essentially glue code between several large, complex components. Your code is simple while the components are complex. Mocking the complex components in order to test the simple code usually ends up having very low value to effort ratio. Instead, a functional or integration test that verifies that all the components work together correctly is simpler to make and more useful in terms of the results it produces.
i've got to heavily agree with you on this. i feel more in control of what's going on in my code... and yeah, often confused by peoples massive opposition to it.
generally speaking if someone's angry about something, they probably don't understand it. otherwise... why not ignore it til it goes away?
