validates_presence_of :purpose : Tag culerity, everything about culerity

Testing PUT requests with Culerity

Sun, 31 Jan 2010 21:22:00 +0000

One major pain at testing with culerity so far was a HtmlUnit bug that causes a ScriptException with PUT AJAX requests in jQuery. When you tried to test an update you got a “java.lang.IllegalArgumentException: The content cannot be null”. Fortunately, this bug is fixed now. With latest HtmlUnit build culerity should run fine, and I tell you how.

I assume you have culerity installed already. If not, follow these instructions for testing Rails apps or these for testing Couchapps.

1. Make sure you have up-to-date versions of celerity and culerity:
$ jruby -S gem install celerity #(gives you celerity-0.7.8)
$ gem install culerity –source http://gemcutter.org #(gives you culerity-0.2.7)

2. Get the latest HtmlUnit nightly build:
$ wget http://build.canoo.com/htmlunit/artifacts/htmlunit-2.7-SNAPSHOT-with-dependencies.zip
$ unzip htmlunit-2.7-SNAPSHOT-with-dependencies.zip
$ cd htmlunit-2.7-SNAPSHOT-with-dependencies/lib
These are the jar files you need to copy into your celerity gem.

3. Find your celerity gem and copy the files:
$ jruby -S gem which celerity
$ cp * PATH_OF_JRUBY_INSTALLATION/lib/ruby/gems/1.8/gems/celerity-0.7.7/lib/celerity/htmlunit

4. The new HtmlUnit needs JQuery 1.4, so you need to upgrade if you haven’t done already. There’s a backwards compatibility plugin for 1.3 if this gives you trouble.

Have fun!

Testing key events with Culerity

Sun, 22 Nov 2009 20:43:00 +0000

The application I'm writing depends heavily on key events. When you press enter in a specific text field, some other field opens, when you press tab, the text fields moves, etc. Of course I need to cover this in my cucumber integration tests. The Celerity API is a bit thin for this purpose: You can fire a, let's say, keydown event - but it doesn't pass through the specific key code.

Actually it's easy when you know how. You can execute any javascript directly on the Culerity RemoteBrowserProxy object. In order to fire a specific key event, you have to create a KeyboardEvent, initialize it with whatever you want, and dispatch it on the element.

Read up the details, especially the meaning of initKeyEvent's parameters in this Javascript API.

I ended up with this cucumber step:

When /^I hit "([^\"]*)" in a text_field with id "([^\"]*)"$/ do |key, id|
  key_code = case key
    when 'enter'
      13
    when 'up'
      38
    when 'down'
      40
    else
      0
    end
  $browser.execute_script('event = document.createEvent("KeyboardEvent");')
  $browser.execute_script('event.initKeyEvent("keydown", true, false, document.window, false, false, false, false, ' + key_code.to_s + ', 0)')
  $browser.execute_script("document.getElementById('#{id}').dispatchEvent(event)")
  When 'I wait for the AJAX call to finish'
end

Note that this is meant to work for Firefox only. For IE you can do a similar thing with createEventObject, see here how.

Couchapp / Culerity glitches, part 1

Wed, 04 Nov 2009 10:07:00 +0000

Do you know what's behind these buzzwords: CouchDB / Couchapp / Sammy.js? Not really? Then please look at this article now: Sammy.js, CouchDB, and the new web architecture. The title says it all.

This setup happens to be the field of my diploma thesis, friendly sponsored and supported by Upstream. During the next months I'll develop a super duper thing with these technologies, and then I'll write 80 scientific pages about it. Yees, I'm not that much looking forward to the second part! Until then, I'm planning to semi-regularly blog about my findings.

I'm not allowed to share the code before I have the diploma in my hands. But, because my workmate Frank Proessdorf is so jealous of what I do, he and I started working on an app with a similar setup on our Upstream Research Fridays, to try things out. Here it is. Don't expect anything yet.

Today I'm going to tell you about some details of my testing setup. My *cough* supervising tutor Alexander Lang already wrote down all there is to know yet about Test-Driven Development with Cucumber-Culerity-Celerity and Couchapps.

But there are a few things that will make your life hard, when the almost perfect Rails testing world has spoiled you as much as me. One thing is that we have to deal with a lot of asynchrony. Sammy renders the page, loads the data from the couch, and whenever the data is there it gets rendered into the page. The best way to do this is via callbacks. I'm going to write another blog post about that soon.

In the integration test the problem is that celerity doesn't behave as it claims it does:

$browser.wait

is supposed to make the test wait until everything is rendered completely. But for whatever reason it doesn't. The result is that your test fails because it searches for your expressions in an unfinished page.

Because of that, in culerity we need something like:

sleep 0.4

after every follow, press and go-to-path step. When using culerity in a Rails environment, this usually is enough. Sammy behaves a bit more unpredictable - it sometimes takes more than a whole second until everything is loaded.

Solution? We can either increase the sleep time a lot, but that's not very nice, the features need long enough to run as it is. Fortunately we can use another method that's build into celerity: wait_while.

I created a div "spinner" somewhere in index.html:

 <div id="spinner"></div>

You can also add an actual spinner gif here. Just take care to place the div outside of your sammy element selector ("#main" by default), because this div gets replaced all the time.

We need to show that div before every route that gets run. In application.js:

before(function() {
  $('#spinner').show();
});

And we need to hide it after your rendering is completed. I haven't found an ideal solution where to do that, it depends on the application you are writing. As a quick and dirty fix, you can add it as a last line in sammy's partial function, in sammy.js:

partial: function(path, data, callback) {
  //...
  $('#spinner').hide();
},

I prefer to have more control about when I hide it, as my partial calls sometimes have nested callbacks. So I put it in application.js, resp. in my controllers, after each render call or in the partial callbacks. I admit this still sucks a bit.

Finally, amend the cucumber step:

When /I wait for the AJAX call to finish/ do
  sleep 0.2
  puts 'Waiting for page to load ...' if $browser.div(:id, 'spinner').visible?
  $browser.wait_while { $browser.div(:id, 'spinner').visible?} 
end

The browser still needs to sleep a bit before it actually finds the spinner div. But with this step in my common_culerity_steps.rb, the features finally run smoothly.