Pivotal Blabs

• Selenium on several machines was failing with Connection Refused errors. This turned out to be caused by IPv6 entries (for example, "::1 localhost") which were added by a recent MacOS upgrade. Commenting out those entries seemed to fix the problem (or work around it, anyway).

• Some people expressed a style preference, in rspec, for "pending" rather than an empty "it" block, to make it easy to search for pending tests. Excessive pending tests may be an anti-pattern. On the other hand, writing pending tests, at least temporarily, may be a good way to sketch out an area of functionality before it is implemented.

• We have sometimes found that editing selenium tests (but not other ruby files) in IDEA is incredibly slow (as in, 30 second pauses). Two things to try are removing the gems directory from the project (in favor of just those gems which you need to be able to look at in IDEA), or at least removing the selenium gems. Another such example is that IDEA can be really slow editing the end of a long fixture file. This is probably IDEA 7.0.3 or 7.0.4.

• Does anyone have any experiences with one of the object mother libraries like object daddy? (Answers at standup were "no, we always wrote our own object mothers in a domain-specific way"). The appeal of a library is that it might help keep track of what needs to be done to make an object pass rails validation.

• Clock.zone now has exists. (Background, pivotal has a Clock class which has a now method which can be implemented either by a call to Time.now for production, or a mock clock which lets tests specify the "time"). This is so that the rails 2.1 features like Time.zone.now have an analog in Clock.

Interesting

• firebug lite 1.2 is out

Ask for Help

We upgraded to rails 2.1 and polonium and our rspecs are not running on CI, but run fine if you simply use rake on the command line.

Check to see if you are using the rake extensions in pivotal core bundle.

Using setTimeout() to wait for DOM to update in JsUnit does not work.

Using setTimeout in tests is not going to do what you want, unless you mock setTimeout. Basically, setTimeout kicks off another thread which is not likely to effect the current test.

Interesting

• "JsUnit has been updated" A new feature available on trunk is a "modern" ui. The modern ui has 2 panes, with errors and failures listed on the left. Clicking on an error displays details on the right. Get this by 1) installing trunk, and 2) specifying "ui=modern" as a parameter.

Ask for Help

• help: "Selecting an iframe with Selenium RC fu" It appears that selenium has the ability to select an iframe, but it doesn't work in selenium rc fu.
  • answer: Apparently the selenium provided in selenium rc fu is an older version

Selenium RC Fu is a fantastic system for testing Ruby On Rails applications. It is the blending of xUnit testing with Selenium. Selenium is a cool system that operates your browser as if a human were sitting there moving the mouse pressing buttons and keys.

Selenium RC Fu is also a remarkable example of the power of open source. It's selenium remotely controlled by rails and ruby. You can learn more about it by viewing the slides for Full-stack webapp testing with Selenium and Rails presented by my colleagues Alex Chaffee and Brian Takita at the SDForum Silicon Valley Ruby Conference.

Now that you are excited about Selenium RC Fu, by law I must inform you that this wonderful testing tool comes with some costs. First, this is the daisy cutter of testing -- problems will be detected, but it won't be too specific about those problems. A failed selenium test will likely only tell you some expected text was not present on the page -- you have to do some digging to discover the real problem.

It's also slow. To be fair, a lot of software is running to do this testing.

So use selenium testing sparingly. A good strategy is to restrict selenium testing to "happy path" testing. These happy path tests become a compliment to other more focused and faster unit and integration tests.

Recently I was about to check in some changes and did a last minute click through of the application. All of a sudden I'm staring at a stack trace. My tests were green and I had functional tests for the failing controller/action.

Tests are like pants -- they cover your backside while you focus on other things like adding features to your application. Suddenly I felt a breeze on my cheeks. Something was amiss.

I'm more and more convinced that Object Mothers are the way to go to manage test data. I owe my introduction to this pattern to David Goudreau.

A few users and items in fixture data so that you can start up your application and test without adding things from the UI... and then let your tests be self-sufficient: make an Object Mother that generates objects for you with sensible defaults. Instead of relying on fixtures, you know you have an object that nobody else will change. Excellent for reducing test fragility.

It can make builds a bit slower, but the test robustness is worth the tradeoff to me.

I'm busy adding it to my Selenium Tests today and basking in test robustness.

Sooner or later, every test-driven developer discovers that they need a superpower - the power to control time. Let's say you're working on a scheduling system. You're going to want to write tests that say, "Assume that it's 2PM on January 3rd and this user does THIS. What happens as a result? What happens at 4PM on January 3rd as a result?"

One of the joys of writing in Rails is the sheer power you have to change your application universe at almost any level you choose. As a result, we've come up with a variety of ways to solve this problem. As it turns out, with great power comes great responsibility. (I'm not sure why I'm going all comic book right now, but let's run with it).