-
Get a monthly update on best practices for delivering successful software.
So, I tried Blue Ridge for the first time yesterday and I thought I'd write down some quick impressions. Hence, Rails Testing First Look.
Disclaimer: We came into this tool so cold our toes froze. We fumbled, we made mistakes, we probably missed really great ways of doing things. I look forward to being enlightened.
Let's do this question-and-answer style: Continue reading »
Topics: rails testing, Ruby on Rails, tdd

Rails Test Prescriptions, the eBook put out by Noel Rappin, Director of Rails Development at Pathfinder, has been picked up by Pragmatic.
Congratulations to Noel - he's done a great job of furthering testing best practices in rails, and this is a great reward. As he said "I’m very excited by this. I’ve wanted to work with Pragmatic for as long as they’ve been publishing books, and I’m thrilled that this particular project will be able to get wider distribution and access to Pragmatic’s editorial expertise and skill."
* The current free “Getting Started with Rails Testing” ebook will continue to be available. If, at some time in the future, there’s a better Getting Started tutorial in the Pragmatic book, it may be offered as a replacement.
* The update site for current Rails Test Prescription owners will continue to be available for the foreseeable future.
* There will be one more official update to the current Rails Test Prescriptions, probably around the end of August. This will wrap up the chapter or two I’m working on, and tie up some other loose ends.
* After that, errata and information about changes to test tools will most likely be handled via this blog and an errata page on the rails test prescriptions site.
This is Noel's 4th book with a major publisher, following Professional Ruby on Rails, wxPython in Action and Jython Essentials. We're happy for Noel and happy to have him at Pathfinder.
Related Services: Ruby on Rails Development, Custom Software Development
Topics: rails testing, Ruby on Rails, Test, Test Driven Development, Testing
Here's a minor thing that bugs me all the time.
I'm writing a functional test:
should "do something functional" get :search,rder_id => @order.id, :user_id => @user.id # and so on end
The get call in that test simulates a browser request. Intuitively, you would (well, I would) expect this request to be identical to a request coming from the actual view, via a helper like link_to("search", :action => :search, . At least, you'd expect that parameters hash in the controller to be the same between the
rder_id => @order.id, :user_id => @user.id)
Makes sense, right? The testing call should set up the same environment as the actual call being tested. Continue reading »
Topics: rails testing, Ruby on Rails, tdd, Test Driven Development, Testing, wapcaplet
What with upward of two people saying nice things about last week’s post, I’ve decided to keep going with part two of a look at some real testing code.
Most code-heavy tutorials show the code but not the tests — I’m doing the opposite here, and showing the tests, but not much of the code. Also, although I’m presenting these tests in chunks, you should realize that there was a lot of back-and-forth from Cucumber to tests to code and some backtracking, most of which I’ll spare you from having to wade through.
At the end of last week, I had run through the tests for spam-prevention code which worked by limiting the rate at which a user could send messages to other users of a particular social networking site. Cucumber was involved, and I think I went off on a tangent about writing lots of tests.
As sort-of promised in last week’s post, I’m going to work through a real-world test example, with an eye toward explaining how and why I tested the way I did. Hopefully, I’ll be able to do this at blog-post length. If not, well, there’s always next week.
This site, which was a legacy rescue, allows users to send messages to each other within the site without having to give away their other contact information. The problem is that nefarious spammer types were creating logins and immediately sending messages to large numbers of the user population, irritating them. After some deliberation, the client decided on a rate-limiting strategy, where a member could only send a certain number of messages in a day, and a new member could send even fewer messages a day. Messages above that point would require administrative action to unblock the user’s privileges.
Topics: rails testing, Ruby on Rails, Test Driven Development, Testing
It's been way too long since I blathered on about style issues. Today I'd like to talk about testing style. This article assumes you are already writing tests and already using something approaching a Test-Driven Development process -- I'm not here to argue about process, at least not today.
Today the topic is the actual construction of individual tests, how to name them, how to group them, where to get data from and the like.
I suspect I'll think of five more things right after I post this, so look for an update sometime in the future. The update will also address all the places where everybody tells me that I'm totally wrong.
Topics: rails testing, Ruby on Rails, Test Driven Development, Testing