Comments on: Testing Groovy code – an undesirable burden?

By: Choice of the week – 15/2010 « Ivko's Blog

Choice of the week – 15/2010 « Ivko's Blog — Sun, 18 Apr 2010 20:44:42 +0000

[...] The next blog post is kind of a sequel (though written by different person) to that from last week on JavaScript. This time it looks from the Groovy language perspective. It actually explains why preventing syntax or type mismatch errors that are usually caught by the compiler in the statically typed languages, does not require writing additional tests. You can see that the mainstream tests that you would write in a compiled language, would do the job of the compiler. [...]

By: Peter

Peter — Wed, 14 Apr 2010 09:00:45 +0000

@Sakuraba That’s another argument and a perfectly valid one. Does it make you more productive? Certainly compared to developing with a static language without such an IDE. I remember when I first used Eclipse and how much quicker development became because I didn’t have to go through the compilation step.

But are you less productive if you use a dynamic language and take a test-first approach? I think it depends on how comprehensively you embrace the test-first philosophy. Also, don’t ignore the benefits you get from the expressiveness of something like Groovy over Java and the newer IDE support that highlights potential missing methods and properties.

As I said, though, it’s a different argument to the ones I focus on in this article. It’s also an argument that boils down more to personal preference and the task at hand than anything else.

@Dierk That’s mostly true. When you are integrating code across teams, a compiler can be particular useful to detect breaking changes in interfaces and the like. But IDE feedback is probably the main benefit people see.

Yes, you can get such feedback from the IDE with Groovy as I mentioned, but bear in mind that there’s a significant difference between a compile error, which is very difficult to ignore, and the simple underlining of method or property. The trouble is, a lot of valid things end up being underlined, particularly if you use a lot of untyped variables, method arguments, and return values. I suspect pair programming can make a significant difference here!

By: Sakuraba

Sakuraba — Wed, 14 Apr 2010 08:45:29 +0000

@Felipe
No, as I said, I write code in both language styles. I dont favor any over the other. I would e.g. much rather work an a Django project dthan working on a Seam project, despite having much more experience with Java than with Python.

The biggest productivity driver is motivation and not a tool. In my experience however libraries written in dynamic languages require extensive documentation to make it easy to get started, because no IDE can tell me what methods you can invoke on which objects. If such documentation is missing, I think then static languages have an edge, because it is easier to build code nagivation tools for them, because a tool just knows which method is going to be dispatched too.

I favor maturity, developer usablity and proof that something has been put to the test much higher than what language it is written in.

By: Blog bookmarks 04/14/2010 « My Diigo bookmarks

Blog bookmarks 04/14/2010 « My Diigo bookmarks — Wed, 14 Apr 2010 04:30:39 +0000

[...] Peter Ledbrook [...]

By: Dierk König

Dierk König — Tue, 13 Apr 2010 19:07:13 +0000

Good blog post but not quite on the target. People don’t seek compiler checks, the seek _IDE_ checks!
And a decent IDE can highlight the code above to show where methods are known at editing time and where they are expected to be known only at runtime.
As a programmer I can match this against my expectations.

In other words, in Groovy you can have as much checks as you want to have, albeit that the tool that enforces them is not the compiler.

By: Felipe Cypriano

Felipe Cypriano — Tue, 13 Apr 2010 18:19:31 +0000

@Sakuraba
Do you think this missing error-as-you-type makes your productivity lower?

By: Sakuraba

Sakuraba — Tue, 13 Apr 2010 16:07:22 +0000

I write code in static and dynamic languages and you have not completely convinced me despite having written a very good blog entry about the subject.

The main point that compile-time-type-checking-people make is the fact that you dont even have to run your tests to find out about the error, whereas in dynamic languages such information is impossible to find out, since anything can be changed/added at runtime.

In static systems you can tell wether your screws are in the right holes BEFORE the car touches the streets. Wether or not the engine works correctly is not the scope however.

By: Tweets that mention Peter Ledbrook -- Topsy.com

Tweets that mention Peter Ledbrook -- Topsy.com — Tue, 13 Apr 2010 15:35:55 +0000

[...] This post was mentioned on Twitter by Dmitriy Kopylenko and pledbrook, groovytweets. groovytweets said: RT @pledbrook: Some thoughts on Groovy/Grails and testing: http://www.cacoethes.co.uk/blog/groovyandgrails/243 [...]