HTMLUnit!

First of all, I just wanna say : You guys at HTMLUnit rock!

HTMLunit is a framework written in Java that simulates a client application to a your webserver, i.e. a browser. This one does that by going to a site, parsing through all the site and executing all javascript it comes across. And it works to! We use a lot of ajax on our site, and everything seems to work. It even handles all the jQuery stuff very well. The guys who developed this framework must really have put a lot of work in reproduction all of them browser bugs out there that jQuery ,among other, tries to solve. Respect.

That beeing said, lets complain a little. But not about htmlunit, but about Java. That damn language is so verbose. I want to execute some javascript and get the result to run my tests. No big deal, but in Java i have to type something like :
(new WebClient (
new URL("http://www.google.com"))).
getPage().executeJavaScriptResult("1+1").
getScriptResult()
where as in Ruby, this would probably be something like:
Web::Client::Page.
new("http://google.com").
js("1+1").result
This ain't a problem if you sit on eclipse, IntelliJ or something. But the thing is, I don't. And then you have to wrap all of it in classes, main etc. I started doing this but then I quickly converted everything to Jruby, or rather I just started programming in ruby instead and let jruby handle the gap between the lanugages.

The blog Scraping Dynamic Websites Using JRuby and HtmlUnit helped me getting started. But I didn't get the tarball there to work. Instead I downloaded the newest version of HMTLUnit from sourgeforge. After a couple of minutes I was up and running.

It first I tried to just use HTMLunit as a javascript runner, and use JSSpec as the testframework. But a) I didn't get it to function like I expected/ wanted to. b) There are some serious state-charing-related issues that has to be solved. So therefore I just hooked it up with rspec under jruby. It gave me a java-horror-stacktrace but then it just worked!

I was running javascript tests from the console, and it was some pretty advanced stuff. 'Did that element fadeout?, was that element updated? Did I get that response from the server'. It worked, but I wanna give a warning about how slow it was. It was about 1 sec / test. So if you have 1100 tests as we have on the backend....

Now it's just to hooked it all up with CI and we're ready to go.

I'll soon be back with a hands-on tutorial on how to set ut everything. 'til then. Bye!

Fixin', Hackin' , Patchin' & givin' up...

I've been trying to get the Crosscheck-framework now. I've solved the problem mentioned in the last post by patching jQuery. It turned out the problem was the how Crosscheck enumerates js-objects. Anyways, once that problem was solved a new one emerged. I was planning on submitting all the fixes for these problems here, but now I reached the point were giving up was the only option. There is no use in trying to get the framework to play with the jQuery-library; the differences between crosscheck and the real browser is to big. Sadly enough.

So what to do next? Either we have to go over to in-browser-testing and in that case I figure we'll go with JSSpec, which is a behavior-driven javascript testing framework. But that is the last resort; if we do our tests in the browser the CI-process is practically impossible. Which means we'll end up not running the javascript-tests, which is kind of equal to not testing at all. The other possiblity is to look at other 'browser simulators'.

John Resig, one of the most quoted javascript gurus here at the office (the other one being Douglas Crockford ), presented an interesting alternative in his blogpost Bringing the Browser to the Server. In this post he supplies a simple browser enviroment to be used together with Rhino (Mozilla's server side javascript runtime). This could then be used for javascript testing. I tried it out, but as he claims in the post, it only supplies the very basic and therefore some important things are missing. I really have to pay my respects to Resig though, the existing work is real nice and if he decides to continuing the work on it, it'll definitely be worth checking out.

So for now we can't go with crosscheck and we can't go with resig's solution. Unfortunately. Next thing to check out is the HtmlUnit framework. It has some SoundCloud specific drawbacks, one of them being that it's written in java, but on the flipside is that their developers have tried it with different versions of jQuery and it seeems to work. So expect to hear more about HtmlUnit from me.