mardi 9 octobre 2007

I want closures in Java !

It's true, trying other programming languages, different enough from your main programming language make you a better programmer/designer in general.

My main programming language is Java, but I also do a lot of Ruby, and it definitely helps me to find new technics in Java.

Now, the problem is : the more I use closures in Ruby, the more I miss closures in Java...

However sometimes, even in Java, the only answer to some OOP problem is some sort of closure, implemented via a callback interface with an anonymous inner class. But the syntax cost of such a construct is very high. All the more so since only final local variables can be used in the anonymous inner class.

So. I do hope closure will make it in the next release of Java.

dimanche 7 octobre 2007

XMLRPC/Ruby presentation for TSP

The slides of my presentation on the implementation of a TSP consumer in Ruby for the first TSP workshop are archived here.

samedi 6 octobre 2007

TDD : state-based testings VS behavior-base testing

Using TDD to write my code I'm still trying to find when I should use mock objects or just test against the whole cluster of objects. That's the difference between state-based testing (no mocks) and behavior-based testing (using mocks) explained in this brilliant article by Martin Fowler : Mocks Aren't Stubs

I'm sure that both technics are useful and I switch from one technic to an other depending on the complexity of the objects I'm testing.

  • State-based testing (no mock) tend to increase the amount of integration test between objects, so is better suited to tests clusters of object with complex interaction

  • Behaviour-based testing (with mocks) tend to increase the test coverage on a given object as it is easier to control the test environment of the object under test


Using mocks objects tend to create more work, but the more I use them the more I detect bugs in my code that would very hard, or impossible to detect with state-based testing.

Last time it happened it allowed me to see that an external object was called and was not supposed to be called (because the mock was called and warned me that it was an unexpected call)

I would have never been able to detect this call with state base testing because :

  • It did not change the state of the object under test

  • It did not change the state of the external object


However the call to the real external object is very CPU intensive and would have harmed the performance. Behavior based testing allowed me to see this, it would have been undetected with state-based testing.

jeudi 4 octobre 2007

TDD, red-green-refactor : red as important as green

When I got started with TDD, I tended to often forget the first step : red

At first, it can seem silly to try to run a test when you did not write the matching functional code. You may think "Of course, it is going to be red ! There's nothing in my application for this feature !"

Of course... Unless there's a bug in your test. And it could be green and you're not going to see it. Then, you write the application code, with a bug too, you run your buggy test, and it is green even with your buggy functional code...

Basically the red step of red-green-refactor helps you debug your test before your code. The red step really is some sort of TDD applied to the test itself. When there is no functional code, a test must be red. It does not mean that the test is correct, but if it is green, surely, it must be fixed.

And even if your test is red and buggy, it is not a big deal, because when your functional code will be written, the test will be red too. The problem could come from your functional code, from your test, or both, but at least you will have to fix something to make the test pass.

TDD like all Agile techniques, is all about rapid feedback. Red gives you feedback about your test, green feedback about your functional code.