On last week’s RailsCamp UK I started hacking on a new CouchApp called HejHej. Its purpose is to help me learn Swedish, but what’s more important here: I wrote this app BDD style using Cucumber, the famous BDD tool and Culerity, my humble addition that allows me to test any webapp (including client side JavaScript) with it.

The whole thing is available on Github so you can check out the features and steps there. In the following post I will show the necessary steps to test your own CouchApps with Cucumber.
(more…)

On Thursday I gave a talk about Bug fighting with TDD and how it will help you to write better software at the Ruby User Group in Berlin. Sorry, I won’t put the slides online, although people asked about it. I think they are a pretty useless collection of keywords and pictures without the talking. Instead I like to provide a collection of links to dive into the whole testing matters.

First a collection of tools you can choose from for various testing scenarios. They all have their pros and cons, it just comes down to which will do the job best for you.

Tools for Unit Testing

• Rspec
• Test/Unit (part of Rails)
• shoulda

Tools for Mocking

• Flexmock
• Mocha
• RR

Tools for Acceptance Testing

• Webrat
• Cucumber
• HtmlUnit (with JRuby)
• Selenium

Tools to generate test objects

• Machinist
• FactoryGirl
• ObjectDaddy

Misc tools

• Autotest
• Tarantula
• Culerity

To save you the initial searching where to start, I collected some links where you find basic information about testing in general or with certain tools.

Getting started

• A Guide to Testing Rails Applications
• An introduction to RSpec
• Functional Testing awesomeness with Webrat
• How I Test Controllers, 2009 Remix
• Shoulda tutorial
• Mock objects explained and intro to Mocha (de)

For everyone who wants to get more into the subject, I drilled down my feed reader to collect some interesting blog posts on testing matters.

Opinions and In-sign

• The Great Test Framework Dance-off
• Thoughts on Developer Testing
• Spikes, test-after, and learning how to test
• A case against a case against mocking and stubbing
• A critical look at the current state of Ruby testing
• One Line Tests Without the Smells
• Mocks Aren’t Stubs
• Testing as Communication: Real-World Techniques Notes
• When duplication in tests informs design
• Writing Code That Doesn’t Suck (vid)

So much for my two cents to make the software world better.

—

Does your company need help with software testing? We can help: check out our new product Scene Investigation.

Last week was my first Erlang gig. I paired up with Jan Lehnardt (core committer of CouchDB). Our goal was to implement a new statistics module for CouchDB within one week. Jan knew more about the CouchDB code and Erlang, I contributed my knowledge about testing and pair programming.

Integration Testing in JavaScript

Since the testing infrastructure in CouchDB left some room for improvement we decided to introduce some new concepts. The existing tests were written in JavaScript penetrating the database via its HTTP/JSON interface. The tests were really long and coarse grained which lead to a problem: When one of the tests broke it wasn’t very easy to figure out which one. We didn’t want to replace or add too much to the existing, self-made test framework so we just added a bit of sugar: BDD style specs with meaningful names:

var response_count_tests = {
’should show the number of 404 responses’: function(name) {
// Given
restartServer();

// When
CouchDB.request(‘GET’, ‘/some_nonexistant_url’);

// Then
TEquals(1, CouchDB.stats_request(‘httpd’, ‘not_found’), name);
}
};

var all_tests = [response_count_tests, ...];

for(var i in all_tests) {
test_group = all_tests[i];
for(var j in test_group {
test_group[j](j);
}
}

The TEquals function is just our extension of an existing function T which is responsible for reporting errors when the assertion doesn’t match. By passing the name of the test spec we can now display that name along with the error message:

Error in ’should show the number of 404 responses’: ‘CouchDB.stats_request(‘httpd’, ‘not_found’)’ should be ‘1′ but was ‘0′.

Unit Testing in Erlang

In addition to those integration tests we wanted to add some unit testing on a lower level. Turns out the only unit testing framework for Erlang seems to be EUnit, which is a very barebones (at least when you come from something like RSpec) xUnit type of tool. You define a test by appending “_test” to your function name and then you have a bunch of assert statements at your disposal. Well that’s at least something and it worked. Here is an example:

should_return_zero_if_nothing_has_been_counted_yet_test() ->
test_setup(fun() ->
Result = ?MODULE:get({httpd, average_request_count}),
?assertEqual(< <"0.00">>, Result)
end).

We added the test_setup for starting and tearing down processes needed for our tests. Then we pass a fun with the actual test code. We got through the week pretty ok with this but I really missed a few things:

Erlang

I’ve read the book, I’ve watched numerous screencasts but this was my first real life project in Erlang. Many people complain about its syntax and while this isn’t the most beautiful language I’ve ever seen I have to say it’s not really a big problem. I got used to it on the first day.

What is really powerful in Erlang is pattern matching. Instead of simply assigning a value to a variable you can always match against the structure of that data to extract parts of it:

Data = {“Hans”, “Wurst”, {born, 1980, 10, 23}}.
{FirstName, _, {born, Year, _, Day} = Data.

This example lets you pull out numerous details from the tuple in a single statement. You can do the same for case statements or when overloading functions. So this pattern matching is a powerful concept seen everywhere in Erlang code. It makes the code you write pretty dense which is cool on the one hand but sometimes also makes it hard to read so you have to be careful how much you want to cram into a single line of code.

CouchDB is built using make – which felt like 1990. I’ve never used make much myself so I’m not really qualified to talk about it but we did spend a good amount of time in our MakeFile because of some whitespace problem, and we still haven’t managed to integrate our new tests into the build process. I’d love to see something like Rake being used instead.

All in all this have been very pleasant first steps though. Pairing up for this turned out to be a very good idea, I have learned a lot about Erlang and am eager for more now.

The DevHouseBerlin weekend is over, but don’t worry if you missed this one. This first one was such a success that we will do more of them.

Thanks to all of those who came, helped, organized and shared their knowledge to make this such fun. I’m not lying when saying that everything turned out to be better than expected.

The upfront organization was minimal. Special thanks to Jan and Alex! We even got some unexpected PR beforehand thanks to an online article about the DevHouse. In response we bumped up the available slots to 20. Which were all filled up soon.

The location Box 119 which houses the offices of upstream, finnlabs and rocket rentals was an ideal location for such an event with its medium large office rooms and a bigger foyer. Box 119 had a solid infrastructure, the WiFi and Internet didn’t let us down once. We even had a decent coffee machine, major factor!

Saturday was packed. I guessed more than 30 people at once filled the DevHouse. Everybody was very open and eager to share. The presentation slots for the evening were filled up already by the early afternoon. I even lost my planned slot because of getting out of bed a bit later than planned.

Right from the beginning major hacking was going on. In the afternoon the talks started. In parallel there was tons of time to chat, eat and hack at will within a very relaxing atmosphere.

PHP raised in my opinion again, after I learned through Falko’s Meta Programming PHP talk that it also has a method_missing equivalent. Nico gave some helpful user experience insights by analyzing start pages on the projector. It’s amazing how many – in retrospective obvious things – you can do wrong on your start page. With Fabian we had a non technical discussion about Economy, after his talk about Fixing Money, which unfortunately left out the solution. After that talk I heard some creepy stories from The Enterprise at dinner.

At 2am at least a dozen people were still in the house. I left at 3:30am still full awake thanks to the optimal Club Mate supply.

Sunday wasn’t that busy. People dropped in later, I had plenty of time to get a presentation slot this time. Some realtime programming battle was going on in the afternoon. You can find Gregor’s battle tank A.I. on Github. Filip showed some quick code kung fu by building a poll app with Django in his talk. This little python Framework is worth a look, if you need to get up small apps fast.
My first talk on Bug Fighting with TDD went well. People seemed to be very interested in the subject. I had some time to play with JRuby and was able to get HtmlUnit to run with Webrat, although my solution is still sort of hackish.

CouchDB was all over the place of course with Jan around. He helped interested folks to get it up an running and helped out with problems related to CouchDB. Alex used the time to enhance his CouchDB persistence layer couch_potato. It will make the transition for rails people much easier.

People who stayed late this sunday – which excludes me – witnessed as the very first the rise of cloudplayer the most beautiful online music player in the world wide interweb, that Erik & Henrik gave the last touches at the DevHouse.

These where just some of the talks, projects and peoples that I get to know that weekend. There was so much more as you can see from the photos and the wiki.

Wow, it was just great. And next time will be even better. We will tell you more soon on this

I recently started using Webrat in one of our project’s test suites and fell in love with it immediately. Webrat is a functional testing library for Ruby on Rails which you can use in your rails integration tests (or better: the RSpec Story Runner) to let your tests walk through your application. The big difference between Webrat and a “standard” Rails Integration Test is that with Webrat you click on actual links and submit actual forms, instead of just sending requests to you application.

This closes an important gap to testing in a real browser (like with Selenium) and now gives us much more confidence in our tests – we now not only know that our models and controllers integrate, but we also know that they work with our views. That had been an unpleasant problem for a while. All our tests were passing but we still had way too many problems with invalid links and forms submiting to the wrong action. No more.

Webrat provides a sort of DSL (everything is a DSL nowaday isn’t it? ) for interacting with all the HTML elements you would find in a HTML document like links, checkboxes, radio buttons, text fields, selects and submit buttons. A test case might look like this:

visits ‘/’
clicks_link ‘Sign up’
fills_in ‘username’, :with => ‘joedoe’
selects ‘Male’
checks ‘Terms of Service’
clicks_button

Webrat now fetches the start page of the application, parses it and follows the first link labelled with “Sign Up”, gets the corresponding page, parses the form, fills in the values and submits it. Whenever a response comes back with anything else than a 200 (or 302, in which case that redirection is followed automatically) or an element on the page can’t be found, Webrat complains with an error and you know there’s probably something wrong in your view.

In Order to get this working with Story Runner I have wrapped most calls into When calls, for example:

When ‘I click on $link’ do |link|
clicks_link link
end
When ‘I submit the form’ do
clicks_button
end
When ‘I select $option’ do |option|
selects option
end

And now my Story looks like this:

Scenario: successful signup
When I go to the start page
And I click on Sign up
And I select Male
And I check the Terms of Service
And I submit the form
Then the page should show Thank you for signing up

I’m not sure yet if it makes sense to release those wrappers as a plugin, we’ll see. After all it’s just a few lines of trivial code.

By the way, Webrat is hosted on awesome github, so after using it for 30 minutes (seriously) I forked my own version and added support for the Rails date helpers (selects_date Date.today, :from => 'signup_date' instead of selects 'December', :from => 'signup_date_2i'; selects '2008', :from => 'signup_date_1i'; selects '01', :from => 'signup_date_3i') and Emails (e.g. clicking the activation link in a signup email). (Bryan Helmkamp, if you read this: Why haven’t you pulled this (and in fact any other fork) into the main line yet?)

All in all the experience has been fantastic. Webrat is on all my Rails projects now. The only – conceptual – problem so far is that I can’t use it to test AJAX. But that’s the topic of another post. And there’s a fork on github that experiments with celerity, which can do AJAX and everything.

We recently introduced a new feature in autoki called the social feed. It’s basically a yellow box displaying any events on the platform relevant to the current user, like a friend has posted a new photo, or a new interesting car was uploaded. The data model behind this is pretty straightforward, we have a FeedEvent class and all kinds of subclasses, e.g. a MessageReceivedEvent. Each event belongs to a user and an event source, in this example the user would be the user who received the message and the event source would be the message itself. For each user, we simply display all the events that belong to him or her.

Now the question was this: How do we create these events? The most straightforward way would probably have been to create them in the models, so the Message model would have an after_create callback that created the event. What we didn’t like about this solution was that we would put a whole bunch of logic into the models that didn’t really belong there. Why would a Message care if there was some kind of event feed? Plus these events would be all around in our unit tests and make the bloated and probably sloooow (again). So we wanted to use the observer pattern to remove the creation of the event from the models.

(more…)

Last week was RailsConf 2007 in Berlin. Only a couple of days have passed and it already seems so far away. Time for some blogging before everybody forgets that it even took place and nobody’s going to read this So here’s the interesting part of the sessions I attended:

A Half-day of Behavior-driven Development on Rails (rspec)

This was the first session on tutorial day and for me one of the most interesting. It basically gave a looong introduction to behavior driven design, how it evolved from things like TDD and who realized what while enganged in which project back in the good old times. One of the interesting parts for me was when they talked about the whole story writing/specification process. I had heard most of it before but it was a good refreshment. The central statement was to write “Software that matters”, and to achieve this, you’d have to get the specs right – as we XPers know this should be done by collecting user stories. The suggested format for such a story was this:

(more…)