One of our client Java projects is pioneering the use of RSpec Story Framework for functional tests.

Overview

RSpec provides two frameworks for writing and executing examples of how your application should behave:

• a Story Framework for describing behaviour at the application level
• a Spec Framework for describing behaviour at the object level

JRuby is an 100% pure-Java implementation of the Ruby programming language.

How can Java projects benefit from RSpec Story Framework? Let’s consider an example.

Example

There is a Java back-end application server with proprietary remote interface. The server manages current states of all patents reviewed by multiple patent offices. Close to real life examples below have no proprietary information and object names has been changed. RSpec can help describe how server works and should be used, also what happens in special conditions.

stories/councilReview.txt

one of stories from the server specification:

Story: patent review by counsel

  A Council review of a patent should change the patent review state
  and affect rolled up state of the patent application case.

   Scenario: legal counsel reviews patent
    Given a patent
    And the patent roll up state is ACTIVE
    When the legal council reviews the patent
    Then patent state should be ON_HOLD
    And patent case rolled up state should be SUSPENDED

   Scenario: legal counsel releases patent from the review bin
    Given a patent
    And the patent roll up state is ON_HOLD
    When the legal council release the patent from the review bin
    Then the patent state should be ACTIVE
    And the patent case rolled up state should be ACTIVE

How it works with Java

steps/patentstateoperations.rb

Steps define our Domain Specific Language or DSL

steps_for(:patent_state_operations) do

 Given "a patent" do
   $patent_state_action_stub = PatentStateActionManager.new("local")
   $patent_id = Random.new
  end

 Given "the patent roll up state is '$state'" do |state|
   patent_state_action_stub.setState(patent_id, state);
 end

 When "a '$reviewer' releases the patent from the review bin" do |type|
    newState = patent_state_action_stub.releaseFromBin(patent_id, reviewer);
 end

 When "a '$reviewer' reviews the patent" do |type|
    newState = patent_state_action_stub.addToBin(patent_id, reviewer);
 end

 Then "patent state should be '$state'" do |state|
   newState.should be state
 end
end

helpers/helper.rb

loads required Java classes using JRuby:

 require 'rubygems'
 require 'spec'
 require 'spec/story'
 require 'java'

 include_class 'client.project.functionaltests.PatentStateActionManager'

 class Spec::Story::Runner::ScenarioRunner
   def initialize
    @listeners = []
  end
end

Dir[File.dirname(__FILE__) + "/../steps/*.rb"].uniq.each { |file| require file }

all.rb

JRuby runs all the stories for the project:

 dir = File.expand_path(File.dirname(__FILE__))
 require "#{dir}/helpers/helper"

 with_steps_for :patent_state_operations do
   run "#{dir}/stories/councilReview.txt"
 end

And since we are on Java Project developers use the above Ruby steps to delegate most of the calls to some Java manager, which serves as a fixture for the functional tests.

PatentStateActionManager.java

This is a Java fixture to pass data to the application via RPC

 public class PatentStateActionManager {

  public PatentStateActionManager(String instanceType) {
  ... // get connection to server via RPC
  }

  public String addToBin(long patentId, String review) {
  ... // call RPC method
  }

  public String releaseFromBin(long patentId, String review) {
  ... // another RPC call
  }

  public void setState(long patentId, String newState) {
  ... // java land, Java developers do what they want
  }
}

Results

As a result we have a executable text specification described in close to English language. Majority of the boiler-plate code contained in Java fixtures and Ruby steps.

Project Managers and Quality Engineers can use RSpec stories to define and exercise the behavior of the application.

Java Developers implemented a few stories to demonstrate the use of all steps for Quality Engineers. In addition to Java unit tests that cover the project code, functional tests cover the application use cases.

Next steps

Quality Engineers will fill the story book with more stories covering many conditions and states.

Java Developers will provide support for fixtures as interfaces evolves over the time.

Customers will define future stories as Pending stories.

And Test Valentines are moving to wider adoption of RSpec including:

• continuous build integration
• test results publishing
• common steps for widely used interfaces:
  • Remote Control of Web apps using Selenium-RC
  • Command line and shell
• interactive console introduction
• functional point coverage

outside of work, I do some things with OpenBSD. Over the last month or so, I’ve been poking at the DRI code, mostly to make it compile on my laptop. Why is it taking so long? I don’t know C, and are learning on the fly. Kernel space makes it interesting.

One problem with compiling: the code uses ‘vtophys()’, which is not portable. My laptop is running in AMD64 mode, which doesn’t have vtophys(). The solution: ‘bus_space_vaddr()’. it essentially is a drop-in replacement for vtophys(), but I have to set up the bus_space area first. Thats proving to be a little more of a challenge than I hoped. I think I’ll have to edit the headers, and add (yuck) some entries into a struct, so I can pass around the appropriate information.

Howdy, everyone! Don’t you hate it when one of your favorite Pivots blogs a non-official, non-blabs article about tea and you didn’t even know about it? It’s just too much effort to subscribe to everyone’s blog individually.

Fret no more! Now you can read and subscribe to every blog post with one easy URL: the All Pivots Blog. Just navigate to http://pivots.pivotallabs.com /everyone. You’ll see all Official, Blabs, and individual posts in chronological order.

A couple of points:

• Exposing the All Pivots Blog reinforces the fact that all posts are public.
• There are no links directly to the All Pivots Blog — you “just have to know”. We still want to drive traffic to the Official Blog and Pivotal Blabs; the All Pivots Blog is mostly for us Pivots, which is why I have not put a working link in this post.

By default, Ajax.Updater will send a POST request to whatever URL is specified. That’s fine, and it prevents certain browser caching issues, but it won’t play well with Rails’ resource routes. Rails will map POST requests to the create controller action, which is not always desirable.

For example, let’s say we have an Ajax.Updater that refreshes a list of posts (GET /posts). Unfortunately, the request that is created by default will be different (POST /posts). You can force the GET method, like so

remote_function(:update => "posts_container",
:url => posts_path, :method => :get))

One problem remains, however. If the URL for the remote_function and the URL for the full (html) version of the resource are the same, as they probably ought to be, and if the Ajax call is a GET request, Firefox will cache the data returned by the remote_function call as the most recent version of the page /posts. When a user navigates away from /posts, and subsequently decides to return to /posts by hitting the back button, the remote_function data will be displayed (as opposed to the full html version of the page). That’s not very user-friendly.

To avoid this, one will need to set the appropriate header:

headers["Cache-Control"] = "no-store"

Interestingly enough, IE7 appears to deal with this situation correctly.