Hacker News Reader

Comment by keyist | Hacker News Reader

If you enjoyed seeing the contrast in approaches between Norvig and Jeffries, you may also find the following interesting -- calculating bowling scores in

1. OCaml, no tests: http://alaska-kamtchatka.blogspot.com/2009/07/disfunctional-...

2. Clojure with unit tests: http://blog.objectmentor.com/articles/2009/07/19/uncle-bob-j...

</amazon>

View on HN

One thing I've never really seen discussed is proving unit test coverage. Taking the clojure example above and its unit tests, nowhere does it make any attempt to show that the few test cases chosen provide a complete coverage of all possible bowling scores. Without that what have you really shown? Sure I can look at it and my gut feeling is, yea that should be enough, but I got that from looking at the OCaml code as well

In the blog post Brad Fitzpatrick is quoted as saying "Write a test. Prove it to me." Now maybe it's my maths background, but when someone say "prove it" a expect proof, and the bowling unit test example proves nothing more than that it works in a few common cases.

Yes I realize that proving anything non trivial in programming is Very Hard, but without any sort of reasonable attempt and even talking about this problem TDD seems more or less ad hoc to me.

You should have a look at QuickCheck. It's a Haskell library where you (more or less) specify laws that your program should satisfy, and it generates test cases on its own. I found it very useful.

QuickCheck is cool. But don't make the mistake of thinking that it proves that the properties hold universally.

Yes. But it's closer to that goal than coding up test cases by hand. (If `closer' is a suitable expression for comparing infinite distances.)

SmallCheck and Lazy SmallCheck seem also to be worth a look. But I did not use them, yet.

Proving test coverage is just as (in)feasible as proving correctness. This is the elephant in the room for testing: it relies on programmer intuition to enumerate cases. It's easy to neglect a case both in the implementation and in the test. This is why tests are better at finding regressions than new bugs.

I can't "prove" my code, but I can prove that my test executes every function, every line and takes every branch and every return. I run my test using valgrind (callgrind with a few options), then I wrote a valgrind parser and combined that with a c++ parser and output the results. Some fun tidbits:

Every time I discovered that a bit of code can never be executed.

The amount of functions that I never even call, even when I am using my test generator (built on top of the same c++ parser)

I enjoy coding. If I spent 1 hour coding a test that finds nearly all of the bugs in a class that means later I wont spent a week deciphering reports and fixing bugs that are annoying users. I get to hack more and my users get more stable code.

If you want to try out my code, http://arora-browser.org/

The c++ parser I used http://github.com/icefox/rpp/tree

My evil little test generator http://benjamin-meyer.blogspot.com/2007/11/auto-test-stub-ge...

My valgrind tools http://benjamin-meyer.blogspot.com/2007/12/valgrind-callgrin...

Unclear on how anybody can cite the author of the latter with any kind of reverence, but I see that happen all the time.

This seems unfair. (a) OCaml != Clojure; maybe the former is better for this problem. (b) Uncle Bob writes I’m trying to learn Clojure, i.e., he admits he's brand new to the language and doesn't (yet) know what he's doing. So, maybe cut the guy some slack?

I reread the Norvig vs. Jeffries posts, and you're right. That example was breathtaking, and it probably colored my judgement about this Uncle Bob example.

Enlighten us folks who aren't methodology scenesters. What is wrong this Uncle Bob guy?

I don't know him from Adam, but his "TDD-based" bowling attempt in Clojure seems like a microcosm of that other guy's Sudoku solver in Ruby.

I asked because I have seen a few other people whose opinions I respect dismiss his writings. So I had to ask.

Cheers!

Intelligent people often dismiss Robert Martin's writings because he has very extreme/condescending opinions about programmming without having the hacker cred to match them. (See 10ren's post above for an example of his condescending attitude and an extreme opinion).

Someone like Linus Torvalds can pull this off, Bob Martin, not so much. Linus nearly always has good reasons for his stated beliefs and agree or disagree you can see why he says what he says. Also he is an acknowledged uber hacker. Bob Martin does write code(Fitnesse) unlike most other agile "guru"/consultant types, but it isn't really anything extraordinary (which is all right, as long as he doesn't presume to then teach other people how to program "correctly").

It is interesting that a great hacker like Peter Norvig is modest and unassuming and chooses his words carefully, as does Knuth for example, while people like Ron Jeffries and "Uncle" Bob say outrageous things with nothing to back them up but faith in their ideology .. err.. methodology .

Well, except that the bowling scores thing had a clear spec from the beginning, and was an easier fit for a blog post. The Sudoku thing seemed more like thrashing around in the how-to-represent-data space to avoid thinking about the algorithm.

Martin Fowler is an enterprise buzzword methodologist. He was into UML, refactoring and patterns and Java back in the days. Nowadays he is into agile, TDD and ruby.

He has a big respect in certain circles, and even I have the Refactoring book, which was a disappointment for me, because it was about practices that was trivial for me after two years of proferssional work, while going into the details too much.

Martin Fowler != Robert C Martin (Uncle Bob)

Oops, my mistake. But the above still holds for Martin Fowler btw. And all those enterprise methodologists look the same to me: they advocate something, but you never see the code they produce, as it is some proprietary crud system at the end of the day :)

His enterprise applications patterns book is superb. An excellent reference to have to hand when you're planning a system. And because it's all written down, you can point to it for substance underneath your decisions when you get skepticism from straight line programmers who just want to start coding without getting excited abuout structure.

The plural of anecdote is not data, but when I worked at ThoughtWorks, Martin sent me some code to look at. It was very clean OO code (very smalltalk-ey in design and form, thought it was written in Ruby). The man can code well (not to the level of say Peter Norvig, but then not many of us can) and competently and is very sharp and when he gets hands on, solves problems fast.It is true that he doesn't have any code online where we can look at it.

Another admirable trait I've witnessed is his willingness to say "I don't know" when asked questions outside his circle of competence. He often says it very bluntly (which has caused some heartburn to some ThoughtWorkers once in a while, but that is another story).

His "Enterprise Patterns" book is very useful for anyone working on enterprise software. I believe DHH was influenced by the book when he was hacking Rails.

His upcoming book on rich gui apps seems promising too. Also he doesn't make outragoeus claims or adopt a condescending atitude to programmers who don't work the way he does/advocates (unlike say Robert Martin). I wouldn't dismiss him as a "know nothing" talker/blowhard.

As I said, just anecdotes. Make of them what you will.

Enterprise Patterns is a classic, that alone redeems the man's non-hackish career.

P.S. I also enjoyed Enterprise Integration Patterns by Hohpe and Woolf.

I know which I would like to maintain.

Reply on news.ycombinator.com