Tag Archive for 'cucumber'

Specify a relative time in Cucumber

Published on August 17, 2009 in programming and web. 0 Comments Tags: , . by cflipse

Prepping for working on a feature at $work that involves limiting documents by relative time, I hashed out the following steps. Posting here in case they prove useful for anyone.

I want to be able to specify an arbitrary time, in english, relative to the current time, in my Cucumber steps. For example,

Scenario: Only posts from the last two months are shown
  Given the following posts:
    | title           | posted_at           |
    | recent post     | 2 days ago          |
    | recent post 2   | yesterday           |
    | older post      | 2 months ago        |
    | really old post | 2 months, 1 day ago |
    | tomorrow's post | 1 day from now      |
  When I go to the posts page
  Then I should see 3 posts

The desire, there, is to be able to specify a date relative to the current time, in plain english. The tricky bit is being able to chain them together, as in 1 year, 3 months, 2 days ago

I got this worked out by stringing a few regular expressions together in my step definition helper. It depends on the 2.days.ago type dsl in ActiveSupport.

Given /^the following posts?:?/ do |table|
  table.map_column!('posted_at'){|date| interpret_time(date) }
  table.hashes.each{|hash| Factory :post, hash}
end
def interpret_time(time)
  return nil if time.blank?
  return time if time.kind_of?(Time) or time.kind_of?(Date)
  named_time(time) || time_by_regex(time) || Time.parse(time)
end
 
def named_time(time)
  case time.downcase
  when "today" : Date.today
  when "now" : Time.now
  # etc ...
  else nil
  end
end
 
def time_by_regex(time)
  directional_regex = /(ago|from now)/i
  time_regex = /(\d+) (minute|hour|day|week|month|year)s?/i
 
  direction = time.scan(directional_regex).flatten
  shifts = time.scan(time_regex)
 
  return nil if direction.empty? or shifts.empty?
  forward = direction.first == "from now"
 
  result = Time.now
  shifts.each do |count, unit|
    #depends on the 1.week type DSL for time measurements
    adjust = count.to_i.send(unit)
    # move time in correct direction
    result = forward ? (result + adjust) : (result - adjust)
  end
 
  result
end

Integration testing SSL with Cucumber

Published on February 16, 2009 in programming and work. 2 Comments Tags: , , . by cflipse

Cucumber, for those who aren’t up to speed on the latest in testing hotness, is an integration testing framework for Ruby. While it’s not strictly limited to integration testing Rails applications, that’s the context i use it in most of the time.

I saw a question on the rspec list recently asking about how you test an SSL required page within cucumber, and I realized that I’ve had that, and even more cert-related chaos, figured out at $WORK, and that I should probably talk a little bit about it.

Simple scenario is that you’ve got some controller on your site that is supposed to only be accessible via https, and you want to make sure it behaves correctly in cucumber. In your standard deployment scenario, mongrel never really sees anything about SSL; that’s all handled by Apache. Apache will set some headers for you, which rails can check to determine if you’re using SSL. Since you’re not testing with Apache at this testing level, you just need to set the relevant HTTP headers.

Given I am using HTTPS
When I visit /payments
Then I should see the payments page

Given I am not using HTTPS
When I visit /payments
Then I should see an SSL error page

If I’m using webrat (which is highly recommended here) this becomes as simple as setting a header value. In recent versions of webrat, that boils down to:

Given /I am using HTTPS/ do
  header("HTTPS", "on")
end
Given /I am not using HTTPS/ do
  # this space left intentionally blank
end

If you’re NOT using webrat, but still at the rails integration test level, the call is a bit uglier

  get :show, { :id => 1234 }, { :https => 'on' }

The get method at the integration test level actually takes a third argument, which is the HTTP headers set on that request. At the functional / controller example level, the same method might work — I don’t know, I havn’t actually tested this at that level, instead I’ve just stubbed the https? method as needed.

Now, for bonus points. At $WORK, I exist in one of those ideal closed environments where x509 authentication actually stands a chance of working. That is, everyone gets a client certificate, which they send to us with the HTTPS request. We check against an external service, see that the cert is good, and viola, we can pre-populate with all sorts of juicy user information. Pipe dream on the internet, but it works well on an intranet. (having worked with this stuff, it’s no surprise to me at all that x509 client certs havn’t even managed to catch on with banks much less the general public …)

Apache takes care of checking the certificate, making sure it’s valid and well formed, and that it’s not in any CRL, and that it’s trusted. Makes my life easier, at the Rails level, we just have to check against the external service and we’re off to the races. And, happily, apache will pass things on in the headers.

Given I use the client certificate for “Joe”
Then when I visit /administration
I should be let in 

Given /I use the client certificate for "(.*)"/ do |cert_user|
  #lookup or generate stub certificate information
  header("X_CLIENT_CERT", certificate.certificate)
  header("X_CLIENT_DN", certificate.dn)
  header("HTTPS", "on")
 
  DirectoryService.instance.stub!(:lookup).with(certificate.dn).and_return certificate.remote_xml
end

I’m hand-waving around some of the stubbing that would have to go on here, as far as generating dummy information goes, but the basic idea should be sound. In this case, I’m stubbing the entire DiectoryService.lookup method for a particular DN, which I set in the headers, and returning “remote_xml” which is a stand in for the XML document that the remote system returns. This lets me cut out the remote system, which wouldn’t appreciate being hit for all sorts of trash data every time the tests run, while still exercising most of the relevant internal code.

The general idea of an integration test is to see all of the pieces of the system working together. At this point, Cucumber is exercising everything in the stack below Apache. Since certificates and x509 client certificates are largely dealt with by apache, we have to stub those ins and outs to work through the rest of the system. The system is otherwise left unstubbed, and we check those integration points during manual testing.