I’ve just pushed the latest version of bewildr: v0.1.9. New in this release:
Bewildr::Application now has proc_id and name methods to return the process ID and the process nameBewildr::Mouse class to wrap the old BewildrClickr dlltoggle_on and toggle_off methodsNext step:
gem install bewildr
Note that there is now a dependency on ActiveSupport >= 3.0
An interesting read:
http://37signals.com/svn/posts/2742-the-road-to-faster-tests
In order to use rspec within hudson, you need to use the ci_reporter gem. The gem extends rspec’s behaviour to include the junit-style output required by hudson. Annoyingly, the documentation for creating a rspec rake task that uses ci_reporter is a bit sparse and not particularly “googleable”, so I’m putting some example code here for posterity. The following is all that is required in a Rakefile for the most basic rspec task that integrates with hudson:
require 'rspec/core/rake_task'
require 'ci/reporter/rake/rspec'
RSpec::Core::RakeTask.new(:all => ["ci:setup:rspec"]) do |t|
t.pattern = '**/*_spec.rb'
end
You can now run the rspec task named “all” within hudson and get pretty results, graphs, and all the other goodness that hudson derives from junit output files. To run the above task:
rake all
Hope that saves you some searching around!
Bewildr – the IronRuby based gem for automated testing of WPF apps – has been updated! We’re now up to v0.1.7. The main changes are:
There have also been some changes in the background… elements now build themselves dynamically based on what patterns are supported by the underlying MS UI automation element. There’s still a bit of ugliness here, but it’s fast being stomped out.
gem update bewildr
What are you waiting for? Go get it!
If you’re upgrading from rspec 1 to rspec 2, details of the differences are here:
http://github.com/rspec/rspec-core/blob/master/Upgrade.markdown
The specific changes you’ll need to make to your rake file can be found here:
Don’t get me wrong – I love cucumber. I’ve been on projects where it has been used successfully and I’d partly attribute the success of those projects to the use of cucumber. It is a fantastic tool for BDD. When used right:
All of this from one tool! Pretty good, huh? Well, like anything good, it comes with costs – those’ll be covered in a later post.
Whether the costs are outweighed by the benefits that cucumber can provide is dependent on how closely the customers, devs and testers are working together. The more blurred the roles of dev and test are and the more involved the customer is, the more value you’ll get from using cucumber. The further the devs are from the testers and the less involved the customer is, the less value cucumber will give you.
There comes a point where the costs of using cucumber outweigh the benefits – and that point comes along pretty quick IMHO. Most of the projects that I’ve seen using cucumber really shouldn’t be. Yes, it’s the flavor of the month. Yes, it’s what all the cool kidz are using. But it’s not a panacea. Using cucumber will not shower your project with pink unicorns or make your team collaborative. Too often I’ve seen cucumber used for CVDD/RDD instead of BDD – almost always a bad move…
Having been on quite a few projects that have used cucumber, I’ve come up with an unscientific and clumsy acid test that will show you if you should stop using cucumber and move to something with lower maintenance costs (eg: rspec/testunit/whatever). Here, in all its glory, is The Chicken Test™:
Instead of your usual feature description, try putting the following at the top of your next feature file:
Feature: [whatever feature is being written] As a chicken I want to cross the road In order to get to the other side
Possible results of The Chicken Test:
All too often, projects I’ve seen fail the chicken test. Does yours?
Get it here:
gem install responsalizr
Responsalizr is a very small and very simple gem I’ve written that extends the standard ruby Net::HTTPResponse class with a few methods to allow for idiomatic testing of HTTP response codes. The methods added are:
code?(integer) #eg: code?(200), code?(404)ok? – corresponds to code 200not_found? – corresponds to code 404moved_permanently? – corresponds to a 301The response type name compare methods are derived from the subclasses of Net::HTTPResponse; you can find a table with their names at the bottom of this post.
Here is an example rspec script that demonstrates what you can do with responsalizr. Each test does the same thing twice; once doing a numeric response code compare, the other doing a response type name compare:
require 'rubygems'
require 'responsalizr'
include Responsalizr
describe "Google" do
it "should respond to the uk homepage with a 200 or an ok" do
Response.from("http://www.google.co.uk").should be_ok
Response.from("http://www.google.co.uk").should be_a_code 200
end
it "should respond with a 404 or not found" do
Response.from("http://www.google.com/bing.aspx").should be_not_found
Response.from("http://www.google.com/bing.aspx").should be_a_code 404
end
it "should respond with a 302 or a moved permanently" do
Response.from("http://finance.google.com").should be_moved_permanently
Response.from("http://finance.google.com").should be_a_code 301
end
it "should be testable through a proxy" do
Response.from("http://www.google.co.uk", {:proxy_host => "63.223.106.54", :port => 80}).should be_ok
Response.from("http://www.google.co.uk", {:proxy_host => "63.223.106.54", :port => 80}).should be_a_code(200)
end
end
Chose whichever way you like (codes/names) and – I’ve only used both above for demonstration purposes.
So, if all you’re doing is testing HTTP responses for their code (whether you want to do that with codes – 404 – or names – not_found) then responsalizr is the thing for you.
About the specific response name methods and their respective codes, here’s a table that summarizes them:
| Response Type Name | Response Code |
| information? | 1xx |
| continue? | 100 |
| switch_protocol? | 101 |
| success? | 2xx |
| ok? | 200 |
| created? | 201 |
| accepted? | 202 |
| non_authoritative_information? | 203 |
| no_content? | 204 |
| reset_content? | 205 |
| partial_content? | 206 |
| redirection? | 3xx |
| multiple_choice? | 300 |
| moved_permanently? | 301 |
| found? | 302 |
| see_other? | 303 |
| not_modified? | 304 |
| use_proxy? | 305 |
| temporary_redirect? | 307 |
| client_error? | 4xx |
| bad_request? | 400 |
| unauthorized? | 401 |
| payment_required? | 402 |
| forbidden? | 403 |
| not_found? | 404 |
| method_not_allowed? | 405 |
| not_acceptable? | 406 |
| proxy_authentication_required? | 407 |
| request_time_out? | 408 |
| conflict? | 409 |
| gone? | 410 |
| length_required? | 411 |
| precondition_failed? | 412 |
| request_entity_too_large? | 413 |
| request_uri_too_long? | 414 |
| unsupported_media_type? | 415 |
| requested_range_not_satisfiable? | 416 |
| expectation_failed? | 417 |
| server_error? | 5xx |
| internal_server_error? | 500 |
| not_implemented? | 501 |
| bad_gateway? | 502 |
| service_unavailable? | 503 |
| gateway_time_out? | 504 |
| version_not_supported? | 505 |
| unknown_response? | xxx |
Because of the rspec (and cucumber) predicate magic, you can use, eg, the bad_gateway?, the forbidden? and the internal_server_error? method as follows:
...should be_a_bad_gateway
...should be_forbidden
...should be_an_internal_server_error
Happy HTTP Response Code testing!
This is not the usual material that I put up, but I’d like to immortalize an event that demonstrated yet again the beauty of Ruby for basic file manipulation, especially in contrast to doing the same in a Windows command shell. Here goes:
“Nat, I need a script that displays a count of the number of instances of a string in a file. The output must be a number and nothing else.”
“No worries, that won’t take 2 seconds.”
“Stop right there – I don’t want any of your ruby nonsense – it must be a batch file.”
“Hmmm… Can the batch file call a ruby script?”
“No.”
“Err… ok… I’ll see what I can do.”
So off I went trawling google, stackoverflow, random blogs, and websites which can’t have seen hits since 1995. One hour, some frustration, and several cups of tea later, this is what I came up with:
findstr /C:"search string" "c:\my\file.txt" | find /C /V "nonsense"
And that, ladies and gentlemen, works! Let me explain what’s going on… The script uses 2 commands: findstr and find. findstr is used for finding strings in files, and find is also used for finding strings in files. It of course makes perfect sense to have two commands that do the same thing – the very definition of the word “intuitive”. In the above example, findstr returns lines from the file that contain the search string. These lines are piped to find which then displays the number of lines that don’t contain a particular string, in the above case: "nonsense". That will return a number. It’s the only way you can get find, findstr or a combination of the two to return a-number-and-only-a-number of the instances of a string in a file. I would love to see this improved – leave a comment if you know a better way to do it.
To demonstrate to myself why doing the above in DOS is crazy, I wrote the same line in ruby:
File.open("c:/my/file.txt").read.scan(/search string/).count
It doesn’t take much explanation: It opens a file, reads it, scans it for a search string and then returns the number of instances it found.
Now. Can we all start using the right tool for the right job please? I know it may involve a bit of learning, but that never hurt anyone. That is all.