Sunday, September 27, 2009

Languages for JVM

The Java language is mature and that in the software development world means that it's dying. The Java language was designed around object-oriented programming but the trend now is moving towards more functional programming (which is arguably better suited in concurrent environments). I've been looking at newer languages built on top of JVM: Groovy, Scala, and Clojure.

Groovy is basically a dynamic version of the Java language with some new language features such as closures (a feature in functional programming). In essence, Groovy is "Java scripted" inspired from Python and Ruby.

Scala is an object oriented language with functional language features. It is not a scripting language and has features such as type inference:

var t = new Tiger();

The compiler knows that t is a Tiger -- no need to do:

Tiger t = new Tiger();

This type information is available at compile-time which allows for compile-time optimizations, making Scala on par with native Java performance.

Clojure essentially Lisp-inspired language running on the JVM.

All the above languages do not differ much with their Java interop (i.e., you can pretty much call existing Java code directly). All reduces the verbosity of Java. If I had to learn one language, I would pick Scala. I think Groovy is too small of an evolution over Java (i.e., not much benefits). Clojure just seems to radical for object-oriented developers.

Here's some additional points in no particular order:

- Martin Odersky, father of Groovy, said "I can honestly say if someone had shown me the Programming Scala book by by Martin Odersky, Lex Spoon & Bill Venners back in 2003 I'd probably have never created Groovy."

- Scala is available both JVM and .NET.

Wednesday, September 16, 2009

Integration test hell

For those of you spending lots of time fixing up integration tests, J.B. Rainsberger explains why he thinks integration tests are a scam:

I think the point he is driving home is that we should be focusing more on comprehensive unit tests rather than comprehensive integration tests. I've started changing how I write my integration tests: They should only be verifying the interactivity of components, rather the expected results of the component.

Let's say that a User Service class (UserService) that calls a User Data Access Object class (UserDAO). The unit tests for UserService should use a mock of UserDao and asserting exact equality with the data and exceptions returned from UserDao properly (-- nothing new here). Your integration tests for UserService should use a real UserDao that is connected database (-- again, nothing new here). However, these types of test should NOT be asserting data and exceptions equality. Rather, these integration tests should just be verifying that some data/exceptions are returned. Integration tests should be testing the seams between the UserService and UserDao components, rather than asserting the equality of the value themselves.

Overally, I recommend watching this talk if you have done lots of unit and integration tests writing and wondering if you are duplicating effort.