This evening, I gave my first presentation of Unit Testing J2EE from JRuby to the Northern Virginia Java User’s Group. It was a very interesting experience. The audience asked some interesting questions — but it was also an insightful reminder of my origins as an engineer. Out of approxiately a 30 member audience, perhaps 4 had done any TDD and only a single one had ever used mock objects. While mocks have their origins largely in Java (at least their initial implementations), it is interesting to see that they have been far more readily adopted in the Ruby community than Java.

Also, Mocha suddenly jumped from v0.5.6 to v0.9?!

So jrsplenda broke when I tried to demo it on my wife’s spiffy new Macbook Air — as I was foolish enough to just ’sudo gem install mocha’.

Who the hell has a public release at 0.5.6 and then another at 0.9? I am so integrating FlexMock into jrsplenda in the next release. I can’t see Jim Weirich doing anything like that.

I’m halfway tempted to redo and give my BDD with RSpec talk to NoVaJUG as a JRuby-Java BDD talk. More people should be doing BDD and not merely those of us working in dynamic languages. Were it so, I imagine that I would encounter far more testable and maintainable code in the Java community.

Slides from the presentation are available here

Last week, I wrote about the pain of Java unit testing. At the end of it all, I said that I would supply some answers “tomorrow”.

One week and one RailsConf later, I’ll call this “tomorrow”.

In the previous article, I listed a handful of commons Java idioms that reduce testability. Three out of four of the issues may be rolled up into a higher level of abstraction: encapsulation kills. The remaining point may be summarized as Spring XML == code that most developers don’t test. Encapsulation prevents developers from injecting mock objects into their code. Without mocks, the unit under test lacks isolation. Without isolation, your unit test is an integration test at best and a massive FAIL at worse.

If you endured a Computer Science curriculum in college, I’m reasonably sure that the professor of your second or third CS class repeatedly hammered home: encapsulation is a key tenet of good object-oriented design. However, many dynamic languages only provide a brief nod, if any, to the encapsulation gods. For instance, Python does not support private or protected members. While Ruby does, it is trivial to route around those protections. What some may not realize is that, in this respect, Java is little different than Ruby.

Yes, that’s right. Java can be a bit on the promiscuous side of things too.

Continue reading →