I've been trying out rspec, a new testing framework for ruby that allows one to better follow the principles of Behaviour Driven Design (BDD). BDD is a step on from Test Driven Design (TDD) approach exemplified in the standard ruby unit test framework. TDD is the process of starting ones development by writing the tests that your new module should pass. As you write each test you then implement the code to pass it and hence, voila, you have nicely designed and robust software. In BDD you approach testing the code from how it is supposed to behave. When liasing with clients this is a better approach as everyone can talk in the same language, essentially in terms of requirements so one can try to get less bogged down in implementation details.
Here are some rspec tests for a class I have been working on:
1 describe ReportHelper do
2 before(:each) do
3
4
5
6 @oReport = ReportHelper::Report.new
7 end
8
9 it "should allow a column to be added" do
10 @oReport.AddColumn( 'First Column')
11 end
12
13 it "should allow multiple columns to be added" do
14 @oReport.AddColumn( 'First Column')
15 @oReport.AddColumn( 'Second Column')
16 end
17
18 it "should allow rows to be added to the report" do
19 @oReport.AddColumn( 'First Column')
20 @oReport.AddColumn( 'Second Column')
21 @oReport.AddRow do
22
23 end
24 end
25
26 it "should only allow rows to be added if columns exist" do
27 lambda{ @oReport.AddRow}.should raise_error(RuntimeError, 'No columns defined')
28 end
29
30 it "should return simple cell values" do
31 @oReport.AddColumn( 'First Column')
32 @oReport.AddColumn( 'Second Column')
33
34 @oReport.AddRow do |oRow|
35 oRow[ 'First Column'] = 98
36 oRow[ 'Second Column'] = 198
37 end
38
39 @oReport[0]['First Column'].should == 98
40 @oReport[0]['Second Column'].should == 198
41 end
42
43 end
Each test has a descriptive string that can be interpreted in two ways: as a test that must be passed or as a requirement for the software. The rspec toolset includes something that will pull out all these strings and give a summary of what testing has been done/what the requirements for the software are. If an auditor asks how the software is tested, bang, there is a full report of the tests. At a practical level (i.e. makes life easier for me) I prefer this to the ruby unit test system where one has to think up meaningful_method_names for each test. The strings are easier to write and read and reduce the need for comments.
Example report:
ReportHelper
- should allow a column to be added
- should allow multiple columns to be added
- should allow rows to be added to the report
- should only allow rows to be added if columns exist
- should return simple cell values
Rspec contains sweeter syntactic sugar than the ruby unit test module. For example, rspec overloads every object in the system with a 'should' method for doing the equivalent of assert tests:
@oReport[0]['First Column'].should == 98
Compare this to test/unit:
assert_equal 98, @oReport[0]['First Column']
apart from more typing, assert_equal has the expectation/actual things in what is intuitively to me the wrong order and I'm always having to correct these lines because the error messages have the terms swapped.
Rspec can test assertions more cleanly:
lambda{ @oReport.AddRow}.should raise_error(RuntimeError, 'No columns defined')
although it's a pity that the lambda is necessary (and probably no 1 noob trap) but with test/unit the following always seemed like a lot of typing:
oError = assert_raises RuntimeError do
@oReport.AddRow
end
assert_equal 'No columns defined', oError.message
rspec is nicely integrated into rails, plugins being available to generate rspec tested controllers and models and suchlike, rake tasks to generate documents (woohoo) etc. It is integrated into netbeans and runs ok on Windows although when the tests are run (CTRL-F6) there is a tedious few seconds wasted in startup time. It is possible to run an rspec server in the background to eliminate this startup but it doesn't work on windows native ruby, it gives an error lamenting Microsofts glorious omission of a fork api.
There is much more to Rspec than this. One aim seems to be to write psuedo testing languages and have clients use these to write stories about what the software will do, these stories turning into a test framework. As the slashdot tag goes, 'goodluckwiththat'. At a practical level, I'm liking rspec even if only as a unit test framework with added syntactic sugar.
Worked first time though 
Peter's Moblog
