Trapped in the internets

Yes, I do like Test Driven Development. It works for me.

What doesn’t work for me are articles like this one by Tim Bray1, or rather their endless number of contradicting comments on what TDD and its properties are. You think you know what TDD is? Time to meet an infinite number of monkeys who have understood it in a completely different way. Or haven’t they?

Some random opinions (with remarks by me):

  • If your tests are too hard to make, you know that your API is too complicated. [link]
  • TDD doesn’t make sense in small projects. [link]
  • Never use mocks unless you’re sure their interface is absolutely stable. [link]
  • TDD doesn’t help when people don’t do it properly. It’s hard to introduce tests when the code base grew too large without them. This is a major weakness in the TDD philosophy. [link]
  • TDD is too expensive. We have had code rot in our automated tests. [link] (When doing TDD, I usually run tests about ten times in each commit cycle. How can your test code rot?)
  • Don’t fall for the seductive TDD trap! In practice, everybody hates it, even if they first thought they liked it. TDD sucks away your soul and desire. [link] (I’m not paraphrasing this last sentence.)
  • TDD is inpractical for anything above bowling card calculators and stacks. [link] (Note to self: I’m waiting for the blog post explaining this on this weblog.)
  • This is not TDD. TDD is Test Driven *Design*. [link] (Hey, why don’t you get a copy of the Test Driven Development by Example book?)
  • My tests are often copied from the REPL that I use anyway for my exploratory coding. It doesn’t feel hard to me to write them. [link]

I like the comment about the REPL. This is an observation that I also made. However, would it help if C++ had a REPL? :->

I cannot escape the feeling that these commenters come from very different backgrounds. Who can I trust there? Whose background is closest to mine? Can these comments help anyone without this context information at all?

Or am I maybe just naive to assume I could learn something from discussions on the internet? NO, don’t comment on this yet! I just realized that I probably am. Never mind. I go read TDD by Example again, that’ll help me more.

I'm bad at drawing cats.

1Wow, this guy even has his own Wikipedia article. I didn’t know him before, though, and I also can’t tell you who it is. Everything looks important when you got the link from the Delicious social bookmarking service’s home page.

Sack Reis fällt um

Sack Reis fällt um

Photos from Munich

A few images from the last weeks. The Bavaria at the Theresienwiese is very large and can be climbed up. I sat in her head together with two other people and looked out. :-)

I also saw the surfers in the English Garden, Anne! :-)

Puzzle: A variation of the Visitor Pattern

Update: Solution posted, see below. :)

The visitor pattern allows to structure programs in conventional OO languages such that a method implementation is chosen based on the type of two arguments instead of just the receiver of a message (a.k.a. the object which a method is called on).

In one of the exercises to the “advanced aspects of OO programming” class, we had to write a little program with an “Expression” hierarchy and an expression-evaluating visitor class, just like in this illustration:

visitor-example

The solution to this exercise as presented to us was to keep track of the current ongoing evaluation in the visitor by using a stack. So, each visit method looked something like this:


def visitMul(mulExp)
  mulExp.leftSubExpression.accept(self)
  mulExp.rightSubExpression.accept(self)
  @stack.push(@stack.pop(), @stack.pop())
end

The important invariant is: When accept or one of the visit methods are called for an expression instance, the overall effect is pushing the result of that expression’s evaluation onto the stack. Consequently, by using accept recursively, the subexpressions’ values can be popped from the stack afterwards.

That solution is not very elegant. There’s a variation of the visitor pattern that solves the problem without using an explicit stack. Can you guess how it works?

Update: For the solution, see the third comment.

Morning in Munich

Morning in Munich

Morning in Munich

Fantastic weather for bicycling to one of the parks. More photos are about to come soon. Be prepared! :)

Best wishes from Munich! :)