I was wondering if really great programmers (Knuth, Kernighan, Torvalds, etc) are advocates of extensive unit testing. I can imagine large projects they've worked on adding them to deal with collaboration scaling issues, but did, say, Knuth use unit tests in TeX? And this doesn't weigh on my decision to use them, it's just a matter of curiosity.
As to your real question, the idea of immediate compilation and "unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be "mocked up."
Of course, Knuth also said*:
Beware of bugs in the above code; I have only proved it correct, not tried it.
Knuth is a super-genius, but just the fact that he doesn't unit-test his code shouldn't be an indication that we mere mortals shouldn't test ours.
InfoQ: Do you believe that other tools and processes such as unit testing, Test-driven development or pair programming also aid in programming effectively in Java?
Joshua Bloch: Absolutely. Unit testing is key. And writing your tests first is a great thing.
Jon Skeet tried unit testing, but all his tests passed with no code.
Or something like that.
Probably not.
Then again all the programmers routinely called "really great" are mega geniuses who wrote seminal software 25 years ago by themselves, usually for other programmers, well before unit testing was in vogue, before version control was widespread, before massively collaborative projects were the norm, etc.
In other words, there are characteristics of modern software development that are arguments for unit testing that just weren't really around back then. Modern really great programmers might be unit testing, it's just that we don't call them great yet.
For the record I hate unit testing. Call it an homage.
In this interview Knuth explains he's not a fanatic unit-tester:
"unit tests" appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t
That's in the same response where he explains how he won a Stanford programming competition (race) while being the only contestant to use punched cards on a batch mainframe -- all others were using these new-fangled interactive terminals on a timesharing system, so of course the second place finisher took over an hour longer than Knuth did.
If (perhaps with the exception of exploratory programming in a totally unknown environment) you're more comfortable with punched cards and batch mainframes than interactive terminals and time sharing, I think it will indeed follow that unit tests won't fit your style;-).
From reading Ayende's blog, I gather that some of his most successful projects did not have any or many unit tests. However, he does use them on many projects, just not all projects as a rule. (again from what I've gathered from reading his blog).
Yes, there are lots of great programmers who practice unit testing. How about Martin Fowler, Robert C "Uncle Bob" Martin, Michael Feathers, and of course Kent Beck. The question is not "Does Jon Skeet practice unit testing" it's could YOU work on Jon Skeet's code and know if you broke it or not? Could you work on your own code you wrote two years ago and know if you broke it or not? and finally...exactly how many QA people do you have at your office? and how much time do you spend with software in QA not generating money for you? How fast can you identify bugs?
Unit testing is something we do to move the cost of developing software up to the beginning, when its cheaper, before 20 QA people start looking at it and before you loose a customer because you could not fix a bug fast enough.
I know I would never hire a developer who thought they were above unit testing, even if they were the most kick ass programmer in the world. Because If he was hit by a bus tomorrow where would I find someone with the exact same brain?
I personally have no idea if these guys do/did advocate formal unit tests
Keep in mind, however, that Kent Beck explains that TDD should be thought of as formalization of the types of practices that great programmers naturally employ without even realizing it. It's for us poor saps who're aren't geniuses and helps us to write far more robust code, make it more adaptable, and prevents one from wasting time on writing a bunch of code that is never used. I have found he's totally on target with that assessment.