While I was there I gave a talk called “Why Ruby, Why Now?” at the first dyncon as well as a talk titled Harnessing Cucumber at Valtech Labs. The first talk was an introduction to Ruby. I have been itching to give an introductory talk for a while and I’m glad this gave me the chance. The audience was a bit more knowledgeable about Ruby than I expected, so some of the items weren’t new to them, however I believe there was still enough in the talk to keep people interested. I also blazed through it since it was right before lunch so maybe people were enthralled merely by my lightning-fast presentation skills. The presentation is available online on Github: https://github.com/aeden/presentation_why_ruby and was created using Scott Chacon’s Show Off.

The second talk I gave was an intermediate to advanced talk on Cucumber where I covered a lot of what I have learned about Cucumber over the last year of using it. Cucumber has become an important part of my test suites because it allows me to test the experience of using my software. This talk covered some of the various command-line switches and cucumber.yml configuration options in the first section and then moves onto testing APIs and CLIs. I’ve found that testing both of these interfaces to my applications has helped tremendously in improving the application and at the same time providing a safety net for refactoring, which is exactly what I want from Cucumber. This talk is available as a PDF and was created using Keynote.

I appreciate the support from both of the audiences and the discussions that followed both talks and I look forward to the opportunity to visit Stockholm again in the not-to-distant future. Thanks as well to Peter Svensson for putting together dyncon and to Peter Lind for opening up the Valtech offices for my talk there.

This evening Corey and I sat down and started looking into how we could make the tests live again. First we attempted to use Capybara directly, but ran into issues when trying to set HTTP headers. The DNSimple API uses Basic HTTP Authentication and thus we needed to set the header for that. We also need to set the Content-Type and Accept headers to ensure that Rails handles the input and output correctly. After peeling back some layers of the Capybara onion we landed upon Rack::Test. When using Rack, Capybara delegates request and response handling down to Rack::Test. At this point we decided to see if we could use Rack::Test directly in our step definitions, and it worked like a charm.

Rack::Test has a module called Rack::Test::Methods that can be mixed into a class to provide it with methods for get, post, put, delete as well as last_request, last_response, header and more. We mixed Rack::Test::Methods into the Cucumber world at the top of our API steps file like so:

Then our steps could simply call the Rack::Test methods directly. For example, here’s how to send the HTTP Basic Auth header:

And to set content type and accept headers:

And finally to actually send requests and test the responses. The entire api_steps.rb as it is right now looks like this:

And here is an example of a Cucumber feature that uses the API steps:

I doubt we’ve ended up with the ultimate final set of steps that can be used repeatedly for testing RESTful APIs, however I think it is an excellent start. I’m still on the fence about how to check the response body, specifically whether it is better to match the response body as a string or to actually parse it and write custom steps for each of the different types of objects, but time will tell.

As usual pairing with Corey resulted in some good code, a usable solution and something that I think others will benefit from as well.