This post is a bit of a follow up to my rant about Unit testing in Scala two days back. First let me tell you that that story actually has a happy ending. Eric Torreborne (creator of the Specs framework) immediately stepped up and helped me, and the problem seemed to be a lack of support for JUnit4 test running, which he subsequently implemented. I’m going to reintegrate
specs into my test suite later today. So that makes me happy. I might still retain JtestR. Actually, it would be a bit interesting to see the differences in writing tests in Ruby and Scala.

I spent some time on #scala on FreeNode yesterday. Overall it was an interesting experience. We ended up talking a bit about the unit testing bit, and Ant integration in particular. I’ll get back to that conversation later. But this sparked in me the question why I felt that it was really important to have Ant integration. Does it actually matter?

I have kind of assumed that for a tool running on the JVM, that people might need during their build process, integration with Ant and Maven is more or less a must. It doesn’t really matter what I think of these tools. If I want anyone to actually use the tool in question, this needs to work. In many cases that means it’s not enough to just have a Java class that can be called with the Java-task in Ant. The integration part is a quite small step, but important enough. Or at least I think it is.

I am thinking that no matter what you think of Ant, it’s one of those established tools that are here to stay for a long time. I know that I reach for Ant by default when I need something built. I know there are technologically better choices out there. Being a Ruby person, I know that Rake is totally superior, and that there is Raven and Buildr who both provide lots of support for building my project with Ruby. So why do I still reach for Ant whenever I start a new project?

I guess one of the reasons is that I’m almost always building open source projects. I want people to use my stuff, to do things with it. That means the barrier to entry need to be as low as possible. For Java, the de facto standard build system is still Ant, so the chance of people having it installed is good. Ant is easy enough to work with. Sure, it can be painful for larger things, but for smaller projects there really is no problem with Ant.

What do you think? Does it matter if you use established tools, that might be technologically inferior? Or should you always go for the best solution?

Sometimes I’m considering using other tools for build my own personal projects, but I never know enough to say with certainty I will never release it. That means I have two choices – either I use something else first and then convert it if I release it, or I just go with Ant directly.

Now, heading back to that conversation. It started with a comment about “an ant task for failing unit tests is severely overrated”. Then it went rapidly downhill to “Haskell shits all over Ant for a build script for example”, at which point I totally tuned out. Haskell might be extremely well suited for build scripts, but it’s not an established tool that anyone can use from their tool chain. And further, I got two examples of how these build scripts would look, later in the conversation, and both of them were barely better than shell scripts for building and testing. Now there is a very good reason people aren’t using shell scripts for their standard building and testing tool chain.

Or am I being totally unreasonable about this? (Note, I haven’t in any way defended the technological superiority of Ant in this post, just to make it clear.)

5 Comments | By Ola Bini | In: Uncategorized | tags: ant, build, haskell, scala. | #

I wish this could be a happy story. But it’s really not. If I have made any factual errors in this little rant, don’t hesitate to correct me – I would love to be proved wrong about this.

Actually, I wrote this introduction before I went out to celebrate New Years. Now I’m back to finish the story, and the picture have changed a bit. Not enough yet, but we’ll see.

Let’s tell it from the start. I have this project I’ve just started working on. It seemed like a fun and quite large thing that I can tinker on in my own time. It also seemed like a perfect match to implement in Scala. I haven’t done anything real in Scala yet, and wanted to have a chance to do it. I like everything I’ve seen about the language itself. I’ve said so before and I’ll say it again. So I decided to use it.

As you all probably know, the first step in a new project is to set up your basic structure and getting all the simple stuff working together. Right, for me that means a simple Ant script that can compile Java and Scala, package it into a jar file, and run unit tests on the code. This was simple. … Well, except for the testing bit, that is.

It seems there are a few options for testing in Scala. The ones I found was SUnit (included in the Scala distribution), ScUnit, Rehersal and specs (which is based on ScalaCheck, another framework). So these are our contestants.

First, take SUnit — this is a very small project, no real support for anything spectacular. The syntax kinda stinks. One class for each test? No way. Also, no integration with Ant. I haven’t even tried to run this. Testing should be painless, and in this case I feel that using Java would have been an improvement.

ScUnit looked really, really promising. Quite nice syntax, lots of smarts in the framework. I liked what the documentation showed me. It had a custom Ant task and so on. Very nice. It even worked for a simple Hello, World test case. I thought that this was it. So I started writing the starting points for the first test. For some reasons I needed 20 random numbers for this test. Scala has so many ways of achieving this… I think I’ve tried almost all of them. But all failed with this nice class loading exception just saying InstantiationException on an anonymous function. Lovely. Through some trial and error, I found out that basically any syntax that causes Scala to generate extra classes, ScUnit will fail to run. I have no idea why.

So I gave up and started on the next framework. Rehersal. I have no idea what the misspelling is about. Anyway, this was a no show quite quickly since the Ant test task didn’t even load (it referenced scala.CaseClass, which doesn’t seem to be in the distribution anymore). Well then.

Finally I found specs and ScalaCheck. Now, these frameworks look mighty good, but they need better Google numbers. Specs also has the problem of being the plural of a quite common word. Not a good recipe for success. So I tried to get it working. Specs is built on top of ScalaCheck, and I much preferred the specs way of doing things (being an RSpec fan boy and all). Now specs doesn’t have Ant integration at all, but it does have a JUnit compatibility layer. So I followed the documentation exactly and tried to run it with the Ant JUnit task. KABOOM. “No runnable methods”. This is an error message from JUnit4. But as far as I know, I have been able to run JUnit3 classes as good as JUnit4 classes with the same classpath. Hell, JRuby uses JUnit3 syntax. So obviously I have JUnit4 somewhere on my classpath. For the world of me I cannot find it though.

It doesn’t really matter. At that point I had spent several hours getting simple unit testing working. I gave up and integrated JtestR. Lovely. Half of my project will now not be Scala. I imagine I would have learned more Scala by writing tests in it, than with the implementation. Apparently not. JtestR took less than a minute to get up and working.

I am not saying anything about Scala the language here. What I am saying is that things like this need to work. The integration points need to be there, especially with Ant. Testing is the most important thing a software developer does. I mean, seriously, no matter what code you write, how do you know it works correctly unless you test it in a repeatable way? It’s the only responsible way of coding.

I’m not saying I’m the worlds best coder in any way. I know the Java and Ruby worlds quite well, and I’ve seen lots of other stuff. But the fact that I can’t get any sane testing framework in Scala up and running in several hours, with Ant, tells me that the Scala ecosystem might not be ready for some time.

Now, we’ll see what happens with specs. If I get it working I’ll use it to test my code. I would love that to happen. I would love to help make it happen – except I haven’t learned enough Scala to actually do it yet. Any way or another, I’m not giving up on using Scala for this project. I will see where this leads me. And you can probably expect a series of these first impression posts from me about Scala, since I have a tendency to rant or rave about my experiences.

Happy New Years, people!

10 Comments | By Ola Bini | In: Uncategorized | tags: scala, test. | #