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.

  class Robot 
  { 
    def type 
    def height 
    def width 
    
    def access(location, weight, fragile) 
    { 
      print "Received fragile? ${fragile}, weight: ${weight}, loc: ${location}" 
    } 
  } 
  
  robot = new Robot(type: 'arm', width: 10, height: 40) 
  println "${robot.type}, ${robot.height}, ${robot.width}" 
  robot.access(50, x: 30, y: 20, z: 10, true)

Republished from Venkat Subramaniam’s Programming Groovy (Beta, p. 39)

…outputs the following:

  arm, 40, 10
  Received loc: ["x":30, "y":20, "z":10], weight: 50, fragile? true

If you’re a Ruby programmer, the second line is going to look seriously bizarre. If you’re not, I’ll explain why. In Ruby, you can pass a Hash (think java.util.Map) inline in a method call with the following syntax:

  foo("param1", param2, :hash_key1 => val1, :hash_key2 => val2)

According to Groovy, when a Map is inlined as a argument to a function, by convention, it is the first parameter on the method. If it is not passed in as the first argument then it is coerced into becoming the first argument. The Ruby interpreter will error if you pass an inlined Hash as any argument other than the last. Forgive me but Groovy’s coercion of parameter ordering is just fucking weird.