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

I’m extremely excited to announce that ERubycon has accepted my proposal to speak on JRuby testing of JEE. ERubycon is unique in that it is expressly focused on Ruby in the Enterprise. While “enterprise” is a squishy term to me (my take on it is “legacy/internal facing/business-to-business/large scale development”), I suspect that the constituency will be somewhat different than the other Ruby conferences that I’ve attended this past year (i.e., RailsConf, RubyConf, Ruby Hoedown, and Ruby East). As the majority of my work falls clearly into the enterprise space, I’m looking forward to ERubycon.

ERubycon is August 15-17 in Columbus, Ohio. I hope to see you there.

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 →

Java unit testing sucks!!!

There, I said it.

Come on, it does. I know, 8 years ago, JUnit was the bees knees. But let’s face it: when you’re working on a project, you’re behind schedule for whatever reason, and you have a deadline looming, where’s the first place that you cut corners?

Unit tests. Always.

Why?

1. Lack of perceived value of testing (in other words: I see the happy path works so what’s your big problem?)
2. No one is going to ever touch this code again after this release
3. Java is just difficult to test

Let’s talk about these….

Continue reading →

I know, I know. Java. Blech!

But if you have to work in Java, instead of something more elegant like Ruby, wouldn’t you like some of the same awesome mocking power that you have come to know and love in Java? Yeah, me too.

Toby DiPasquale turned me on to jmockit. It’s a little framework that provide RSpec-like mocking in Java. To those familiar with RSpec: jmockit allows developers to mock constructors as well as individual method on live objects. It accomplishes this courtesy of the java.lang.instrument package that was added in Java 1.5.

I was curious to see if it is possible to mock boot classloader loaded classes (i.e., java.lang.Integer, etc.). After a few minutes of tinkering, I found a way but it’s none to pleasant…

Continue reading →

Chris Sepulveda recently wrote a great article discussing why he believes that Ruby and Rails will ultimately topple Java in the enterprise development space.

He’s not the only one. I’m often hearing Rubyists talk about how, once the Java community “crosses the chasm”, we’ll rule the world. I seem to recall that Smalltalkers had the same notion at one point…

And yet Chris drew an analogy that caught my eye: “Rails is not unlike other early-technulogies in this regard (consider Java in 1996-98).”

I often use a similar analogy when attempting to introduce Ruby and Rails to other Java old-timers: “Remember Java way back in 1997? Yeah, that’s Ruby right now” implying that fame, fortune, and glory await but a few years away for those who hop on those Rails now.

To an extent, the analogy holds. Between ‘96 and ‘98:

• Java was slow as a dog. (Ruby: check)
• Java was immature. There were few class libraries available. (Ruby: hrmm… let’s come back to this)
• Sun/Java struck gold with J2EE v1.0 in ‘98-’99. (Ruby: Rails - check)
• Arguably, Java web development didn’t achieve “maturity” until early versions of Struts appeared on the scene and provided structure that was sorely lacking within the typical J2EE app pre-’99 (Ruby: Rails - check, Merb as well)

However, I still have some reservations about this analogy. As of ‘98:

• Java had been around for 3 years. As of today, Ruby has been around for 13 years. It wasn’t until recently with Rails that Ruby came out of the Sinai and found its land of Milk and Honey — maybe.
• Java had Sun vigorously evangelizing Java like the snake oil of the millennium whereas Ruby, instead, has several small consulting firms and a vocal community of passionate developers (myself among them).
• Java had a pittance of available libraries whereas there are a plethora of available Ruby libraries today.

Let’s face it: in the enterprise, more often than not, it’s not the engineers who pick the technologies: it’s the pointy-haired morons who wear ties to work every day, have stock in the company, a sizeable six-figure income, drive a BMW (bullshit on the inside), and pick technulogies that are “safe” (i.e., they cost lots of money — like Oracle or Microsoft) instead of technologies that can save money (like Linux or Ruby or other OSS).

Of course there are small pockets where sanity reign. One of Chris’ commenter’s henpecked Relevance’s Streamlined framework; however, Stu will tell you that they often submit two bids for their contracts: one to be implemented in Java and the other Ruby. Do I really need to tell you which bid most of his customers pick? What does Relevance use to implement many of their web apps? Stu told me that they built Streamlined to help them quickly develop web apps that, while they won’t win beauty contests for web design, handily get the job done and can be constructed in short order.

At the end of the day, to the enteprise, shouldn’t that be what matters? More value for less money? We engineers often tend to be idealists. If one technology does something better than another and can easily be adapted to play well with the technologies of the past, we deem it a winner. Sadly, the best ideas often lose despite technical merit.