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?
This guy must have been joking.
The fact that HE always types his passwords alone in his office does not mean that any sane person would like a possibility that anyone ever has a chance to see his password. Apparently, some people are not always alone...
"Of course, a truly skilled criminal can simply look at the keyboard and note which keys are being pressed. So, password masking doesn't even protect fully against snoopers.
"More importantly, there's usually nobody looking over your shoulder when you log in to a website."
I agree with this statement entirely, but wonder if in a mobile setting, like with an iPhone if this isn't a bad idea. There have been many times where I tried to look over at someones iPhone to see what they were doing and simply couldn't see. I'm talking as close as 2 feet away.
And since I know how annoying it can be to type passwords on my iPod Touch, I could see the value of this--but only on devices with very small screens, and WITHOUT any sort of auto-fill from the browser. Of course, it should be an opt-in sort of setting. No vendor should decide your fate when it comes to security decisions like this.
It is not very object-oriented the way HE used it, but, being a long time Spring user I can assure you that it is a case of misuse. Spring does not force you to use setter injection (it supports constructor injection) and it certainly does not force you to use anaemic domain model (although many people are doing it).
A fool with a tool is still a fool, I'd say.
If you want to learn to speak French and use it actively, not just to prepare for some exam, I can recommend French In Action from my experience. It is a base for a 2-year course at Yale University. The whole course revolves around a story about an American student on vacation in France, a French girl, and their families. A complete multimedia course consisting of 52 30-minute video episodes with commentaries, 2 textbooks (500 pages of transcripts, visual aids and readings), 2 workbooks (1000 pages of exercises), 1700 audio files aiding the workbook and 2 study guides (400 pages). There is material for roughly 2 hours a day study for year and a half, but it'll get you to the level where you can easily live in France (or Quebec :).
I've just tried Wolfram and I would say that Wolfram is to Google as a Statistics section in a library is to Google. In other words, nobody except geeks will care.
Impressive technology, BUT...
I've just tried Wolfram Alpha with a preview account, and I have to express my complete disappointment. It seems to me that Wolfram Alpha is a classic example of geeks building application that is useful for them but that is irrelevant to the other 99% of the world. And that 99% are the buying customers.
I tried some usual web search phrases, and for each of them "Wolfram wasn't sure what to do with my data". It even suggested some alternative searches, but when I clicked, it still wasn't sure.
Of course, it was happy to analyse some sinus function for me, but imagine how many people would like that?
In my opinion, Wolfram will be an excellent niche search engine for mathematicians, statisticians, and the geeks alike, but nothing near Google in any respect.
This and Google are serving two different purposes. Google is an interface to search the web. Wolfram Alpha is an interface to search their own database of facts and relationships. When you use Wolfram Alpha you are doing a fact search, not a web search.
That little learning for technically literate (small percentage of users) could be a show stopper for the rest. Many people are scared of even the simple maths (sad but true).
I'll probably waste some time contributing to open source projects and then invest into hookers :)
Really, if your only reason to do a startup is to do something else after that - why bother?
If you like contributing to open source projects - contribute now! You like drugs and hookers? What stops you now?
