Posted by Rick DeNatale
Wed, 26 Mar 2008 21:30:00 GMT
I was adding to an existing controller today at work and I was stumped because one of the examples in its controller spec was failing due to an exception thrown while rendering a view.
Normally RSpec controller tests, which are usually used to specify controller logic, bypass view rendering unless you specifically use the integrate_views method in the example group. The idea is that you should use view specs to specify the logic and output of views.
Since I was working in existing code, which pre-existed my being here, I’d followed some of the existing example groups in the file. These would typically look something like this:
describe HobbitController, "doing something" do
before(:each) do
@controller = HobbitController.new
end
end
I finally realized that that first line in the before block was clobbering RSpecs ability to control whether or not views should be rendered. RSpec actually creates the controller instance variable for you, and extends it with a module which overrides the render method to allow integrate_views to control the rendering while allowing the expect_render expectation to work whether or not rendering actually happens.
So I’ve got a new task to clean up all the other controller specs.
Posted in rails | Tags Rspec | no comments | no trackbacks
Posted by Rick DeNatale
Fri, 08 Feb 2008 15:38:00 GMT
One of my current Rails projects involves generating an RSS feed. While I was working on this the other night, it seemed to be working, so I deployed it to the staging server. Everything looked fine. If I fetched it with Firefox, the browser offered to let me subscribe to the feed with Google Reader, and if I used Safari I'd see a nice view of the feed just like I expected.
So I sent a note via our campfire to check it out, and a colleague replied that his Safari was saying that it was in an invalid format.
So I went to the W3 RSS Feed Validation Service and worked through the validation issues, after which his browser was as happy as mine.
Of course, having been through that, I wanted to make sure that RSS validation was covered in the specs for the project.
I went looking for an existing RSpec matcher, and found a matcher to validate XHTML but nothing for RSS.
I then found the feedvalidator gem which provides a Ruby interface to the SOAP interface to the W3 feed validator. You would think that W3 would be providing a REST interface! The gem already provides assertions for use with Test::Unit, so I just built an RSpec matcher.
class BeValidFeed
require 'feed_validator'
require 'tmpdir'
require 'md5'
def matches?(response)
return true if validity_checks_disabled?
v = W3C::FeedValidator.new()
fragment = response.body
filename = File.join Dir::tmpdir, 'feed.' + MD5.md5(fragment).to_s
begin
response = File.open filename do |f| Marshal.load(f) end
v.parse(response)
rescue
unless v.validate_data(fragment)
@failure = " could not access w3 validator to validate the feed."
return false
end
File.open filename, 'w+' do |f| Marshal.dump v.response, f end
end
v.valid?
end
def description
"be valid xhtml"
end
def failure_message
@failure || " expected xhtml to be valid, but validation produced these errors:\n #{@message}"
end
def negative_failure_message
" expected to not be valid, but was (missing validation?)"
end
private
def validity_checks_disabled?
ENV["NONET"] == 'true'
end
end
def be_valid_feed
BeValidFeed.new
end
I saved this as spec/be_valid_feed.rb
And in a view or controller spec, I can include this file, and test a response with:
response.should be_valid_feed
If you use this in a controller spec, you will need to tell RSpec to integrate_views, or you won't have much of a feed to check. If you use nested example groups, integrate_views needs to be inside the inner group.
Posted in ruby, best_practices, rails | Tags Rspec, rss, validation | 4 comments | no trackbacks
Posted by Rick DeNatale
Tue, 29 Jan 2008 21:24:00 GMT
About a year ago when I first encountered RSpec, I thought that the idea sounded good, but I was concerned about how much the implementation at that time pushed new methods into Object and Kernel. It felt to me as though it could interfere with the code being specified/tested. Indeed back then there were some problems when RSpec and Rails bumped heads over the use of certain Ruby metaprogramming techniques. I’d been a TDD user advocate for many years, heck I was there right after Kent Beck, “test-infected” Erich Gamma and sat in on some of their early pairing sessions during an annual OTI company technical conference at Montebello in Quebec, when JUnit was in it’s infancy. The cleaner language of RSpec did have it’s attractions, particularly in trying to get across the idea to newcomers that TDD was really writing mini-specifications rather than tests, which helps put them in the right mindset, but for those of us who had already crossed that paradigm shift, or been born on the right side of it, it didn’t seem so important.
Since then the RSpec implementation has matured, and after talking to David Chelimsky and Dave Astels at RubyConf, I decided to give it another look, and, armed with a new perspective on the use of mocks and stubs to isolate specifications and tests in BDD/TDD, I quickly became a convert. I still use other frameworks as external requirements dictate, but RSpec has become my first choice.
These days, though the choice of testing/specification framework seems to have become one of those religious issues which divide the community, almost as much as emacs vs. vim vs. textmate. I run into people all the time who reject RSpec because it’s “too magical!” Although I’ve never been able to get them to expand on that thought. Perhaps it’s based on the kind of concerns I had about it at first, maybe it’s something else. I’d love to have it explained.
And like advocates do, other arguments get expressed, some of which don’t get the scrutiny they deserve.
Read more...
Posted in ruby, rails | Tags bdd, Rspec, tdd, TestSpec, TestUnit | 3 comments | no trackbacks
