huesler informatik

Rails handles exceptions that occur in production mode by rendering the file public/500.html or one of the other two (404.html and 422.html) if appropriate. Generally this is a good default, but in some cases it is a requirement to redirect the user to, or render specific pages for different types of exceptions. For instance, when an application provides a JSON API, it would be bad to return a 500.html to the caller when something goes wrong.

There are generally two ways do this in Rails. Either overwrite rescue_action_in_public in your controller or use the newer rescue_from to map exceptions to a handler. Ryan Daigle wrote a short but comprehensive blog post on this topic.

However, testing this is a bit tricky. config.consider_all_requests_local needs to be set to false and local_request? should be set to false as well. Testing this manually in the browser is cumbersome and error prone, so I needed a way to verify the behavior with a controller test. A quick ack –ruby rescue_action_in_public actionpack-2.3.4 turned up /actionpack-2.3.4/test/controller/rescue_test.rb exactly what I needed.

As it turns out, this is actually quiet easy to test. Basically, there are four things to consider and you are good to go:

1. Simulate the production environment in a setup method

2. Create a dummy controller with actions that reproduce the errors you want to test

3. Generate a route for your dummy controller if you have deleted the default routes in routes.rb

4. Call those methods in your test cases

With these four steps we got most uses cases covered. I ran into a problem, where I wanted to test an error that occurred during template rendering and required some special exception handling code. This is what worked for me:

Testing translations in integration tests is always controversial topic. Clemens did a great write up providing three solutions and giving suggestions. Here is the link.

Today, someone asked about acceptance testing of iPhone applications. I answered that there are unit testing frameworks for objective-c but no solutions similar to what Selenium is for web applications.

An hour later during a boxing bag session, I do this to clear my head and as a replacement for cigarette breaks, I figured that my answer was probably wrong. It was based on information I have gathered a few months ago. So I decided to do my homework and brush up my knowledge.

Apple has written a great introduction about unit testing for objective-c. That’s a good start, but since an iPhone application is rather GUI heavy, I want to drive the user interface and access its components. In addition to that, I want to assert conditions, otherwise it would be a simplified macro recorder.

Recently I have read Scripted GUI Testing with Ruby. I really liked how the author used RSpec and its story runner to test applications. So I figured it would be great to drive an iPhone application in a similar way, preferably with something that works like Cucumber.

Matt Gallagher has found a way to run automated, scripted tests on an iPhone app’s user interface. Basically, he creates a category on UIView with a method that can be called on any UIView object to get a description of it and all its children. To make selecting a specific element easier, he converts the description to XML so that one can use XPATH queries. He also dug deep into undocumented cocoa code to be able to simulate touch events. Those are needed to manipulated the user interface.

There is a project called bromine which uses Matt’s approach to do automated user interface testing. That’s a good start but I don’t really like to write my tests in XML. XML is meant for machines to read, not humans.

Ian Dees, the guy who write Scripted GUI Testing with Ruby, seemed to have the same feeling. He took Matt Gallagher’s code, made it work with Cucumber and called it brominet. He also gave a great presentation on that topic. This is definitely an interesting approach, especially because it uses Cucumber.

Last but not least, I stumbled upon a project called uispec. It’s a BDD framework which is modeled after RSpec and drives the iPhone UI. The tests can either be written in objective-c or a DSL called UIScript. I gave their sample project a try and recored a video showing it in action.

I must say, uispec looks very promising. Especially the control selectors look simple and straightforward, even though the console output could be a little bit nicer. One thing I don’t like are all the warnings the compiler produced. For the sample project, I got 132 warnings. For example:

warning: 'UIQuery' may not respond to '-text'

In my opinion, compiler warnings should be treated as errors and therefore should be resolved. I don’t like to work on a project, that generates over 100 warnings just because a test framework is in use.

For now, I think a combination of uispec and Cucumber would be my preferred solution to do automated iPhone testing.