Rails Prescriptions 24 Hour Window Blog

Back in the Saddle Again

2009-10-20T23:48:20-05:00

A number of updates, since it’s been a while since I posted anything remotely update-y.

First off, as those of you who follow me on twitter already know, there’s been a change in my employment status. Starting Monday, I’ll be working for Obtiva. I’m very excited about this. I like to do a lot of different things &emdash; code, lead teams, coach, do training, write &emdash; and it looks like I’ll get the chance to do pretty much all of them at Obtiva. Some of you reading this were helpful either by offering support or helping me make a connection, thank you all.

Obtiva doesn’t do a company blog the way Pathfinder does, but I’m hoping to continue to write about Rails, software development, TDD, or whatever else springs to mind. I do think I might switch to a different blogging platform though, the spam attacks are getting to be a little to much for the haphazard install I’ve got going here.

As for the book, it’s moving along. Oddly, job hunting actually didn’t give me as much time to work on it over the last couple of weeks as I was hoping. All the text has been converted to Pragmatic markup, we’ve come up with what I think is the new structure of the book, which groups chapters by common topic more strongly than the original structure did. Hoping for a round of editing based on that structure to be completed shortly, and then we’ll move on to the last round of new chapters, and whatever other review and edit processes come next.

A Given/When/Then Test Framework

2009-10-04T23:29:06-05:00

Jim Weirich put up a potential Ruby test framework that steals the Given/When/Then syntax from Cucumber. I spent some time noodling along similar lines some months back but never got very far with it. Interestingly, Jim’s proposal and my idea seem to be a little bit different, so I thought I’d write up what I was trying to do, and maybe actually try and make it real.

I was thinking about a particular problem that’s easiest to see in a Rails controller test. Using Shoulda, and trying to use a nested context, one assertion per test style, I was trying to test admin and regular user behavior in a particular controller. I started with something like this:

  context "GET edit" do

    setup do
      @proj1 = Project.make(:name => "Project Runway")
      get :edit, :id => @proj1.to_param
    end

    should "have something" { assert something here}
  end

Fine and dandy, but when I want to split this into admin and regular users, what I really want to do is this, bear with the slight pseduo-code:

  context "GET edit" do

    setup do
      @proj1 = Project.make(:name => "Project Runway")
      get :edit, :id => @proj1.to_param
    end

    context "with a normal user" do
      setup { @user = login! }

      should "have something" { assert something here}  
    end

    context "with an admin user" do 
      setup { @user = admin! }

      should "have something adminy" { assert something here}
    end
  end

Unfortunately this doesn’t work, since the get is called before the subordinate setup clauses, the user doesn’t take effect until after the controller call has been made. The workaround is to move the get call into the subordinate setup clauses, which is hardly the end of the world or anything like that but which did bug me a little.

Thinking about this, it occurred to me that the user set up is basically Given, while the get call is basically a When, and what I want to do is insert a new given, while keeping the same when.

I never did quite nail the syntax, but I was hoping for something like this

  Scenario "GET edit" do  
    Given { @proj1 = Project.make(:name => "Project Runway") }
    When { get :edit, :id => @proj1.to_param }

    Scenario "For a normal user" do
      Given { @user = login! }
      Then { assert something here}
    end

    Scenario "For an admin user" do
      Given { @user = admin! }
      Then { assert something here}
    end
  end

The semantics of this is that any Then clause would trigger a test, first all the Given clauses would be run for all nested scenarios, then all the When clauses, followed by the Then block, which would need to return true for the test to pass.

I never got around to implementing it, in part for lack of time, and in part doubting whether this occasional case would be worth the extra effort. As much as I like how the Given/When/Then structure reads here, I’m not sure that it would be clear to a reader of this test that the subordinate Given clauses would be executed before the When clause. Though I guess that would come after some time with the framework.

Thoughts? Am I crazy?

Pragmatic Status and Some Q&A

2009-08-30T15:27:35-05:00

I certainly hope some of you are wondering how the transition to the Pragmatic version of Rails Test Prescriptions is going. Here’s some notes.

Right up top, I want to mention that I’ll be presenting at Windy City Rails on September 12th, with a talk called “How To Test Everything”. There are, I think, still some seats available for the conference, and I’ll get the slides up online as soon as I can.

The self-published version is now off sale—the text on this site will change shortly to reflect that. The update and registration pages are still up, so registered users can continue to download revision seven of the book.

A couple of people have asked me if Pragmatic is going to have some sort of special deal for people who have purchased the self-published version. My answer is in three parts. First off, I don’t know and I’m not the person who would make that decisions. Second, I’d be surprised if they did something directly, the logistics from Pragmatics perspective seem like a pain. Third, without promising anything, I am hoping to do some kind of acknowledgement of the people who bought this book originally, but it’s too soon to tell what form that might take.

Right now, moving the book forward is happening along two different avenues. First, translating my text, which is Markdown, to Pragmatic’s XML/DocBook-like markup. It’s not quite fully automatable, but with the power of TextMate behind me, it’s going fairly quickly. The main slowdown is the sections with actual live code (as opposed to example snippets that aren’t really in a live app). Loving that I can still write in TextMate and build PDF’s from the command line—a wonderfully geeky way to work.

It looks like 1 self-published page is about 2/3 of a Pragmatic page. We’re tentatively hoping that the book as published will have at least 250 pages of text, so if you do the math, that means that at least 25% of the Pragmatic book will be completely new—some new topics, extensions of existing topics, probably a bit more on the TDD process rants, of which there is less in the book than I thought (everthing existing will be updated and polished, of course.) I know what a lot of that new ground is going to be, but I’m open to suggestions as well.

The other avenue I’m discussing with my editor is the structure of the book. The self-published version was originally conceived as something like a recipe book, but it’s not really much like a recipe book at the moment. We’ve decided not to publish it as a recipe book, which means reordering the somewhat random chapter order into something more coherent, and probably consolidating some of the smaller chapters together. Ideally, this will make the entire book easier to follow and easier to browse.

One last thing: I’ve had some questions on how I reconcile the “this book will always be up-to-date” things that I’ve written with dead trees. Fair question. Here are some answers:

I am large and contain multitudes.
Pragmatic is unusually good about keeping their content up to date with e-book updates, and also with public, maintained errata pages on their site. I felt the book could still be kept relevant for a long time.
It dawned on me sometime over the summer that I has basically set myself up with an infinite task and I’ve been trying to think of a way to make doing this book more manageable. I like that the book part of this now has something like an end point, then I can try to keep everything current in some other way.

Rails Test Prescriptions update version 7

2009-08-26T08:57:36-05:00

Rails Test Prescriptions update 7 is now available.

The biggest changes are:

New chapter on Webrat
Expansion of my Pathfinder blog post on what to do when tests fail.

Also, a bunch of typo fixes and what not.

This is most likely the last revision of the self-published version of this book. Although the book itself will go off sale Aug 28, the revision will continue to be available for registered users going forward.

This blog will, of course, continue, watch for news on the Pragmatic version as well as the occasional cranky rant.

Future changes will be handled via an errata page on this site, and probably also blog posts here.

Thanks for your support.

Rails Test Prescriptions to be published by Pragmatic

2009-08-18T09:17:28-05:00

Let’s lead with the headline:

Rails Test Prescriptions is going to be published by Pragmatic.

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.

Thanks to everybody who has supported this book. I can’t express how much I appreciate your attention and enthusiasm. You have made working on this book a pleasure.

Here’s what this means for you:

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 this site.

It’s relevant to mention that this update would likely have been the last new content in the book even without Pragmatic’s interest.

The current version of “Rails Test Prescriptions” will go off-sale, and will be removed from Lulu.com as of August 28, 2009.

This all happened quickly. As much as I’ve loved self-publishing, I’m looking forward to working with Pragmatic. A few weeks ago, after Gregg Pollack’s mention on the Rails weblog spiked sales for several days, I figured that there was never going to be a better time, and I submitted the book to Pragmatic. The theory being that if they said no, I still was enjoying doing the book myself, but if they said yes, it’d really be an opportunity to take this project to the next level.

Pragmatic surprised me not just by agreeing to publish the book, but by turning the whole thing around so quickly—just about a month from initial contact to signed contract. And even though I would definitely self publish again, I’m looking forward to some help on the parts of the book process I’m not that strong on (cover design, marketing, etc…).

I will know more about what happens next later this week after I start talking with my editor at Pragmatic. I suspect some reorganization will take place, as the book changes from merely individual chapters to a more coherent whole. Timeline, exact content, and other issues have yet to be determined, but I’ll keep you all posted here as I know things.

Thanks again to all those who have written me with praise and criticism, and especially to those of you who have pointed out errors of fact, grammar, or clarity. This process has been much more fun because of you, and the book is better for your attention.

Version 006 Now Available

2009-07-06T22:30:19-05:00

Well, it’s been way too long, but revision 006 is now up at Lulu and on the download page of this site.

The two biggest changes are a new chapter on Rcov, and a general read-through and edit of the entire manuscript. Here’s the entire changelog:

New chapter on Rcov
Typos fixed from Dana Jones, Keith Gautreaux, and Greg Lockwood
General fixes to things like external links
Some more clarity in the mocks chapter
Better discussion of setup blocks in setup chapter, also a much more detailed discussion of contexts and nested contexts
Error in RSpec matchers section corrected
Cucumber section benefits from more experience
Couple of layout experiments. Per a suggestion from Jim Zajkowski, I’ve moved the sidebars to the right to enhance readability. I also changed the code font to Anonymous Pro.

Also, welcome to all the new readers, and a big thanks to Gregg Pollack for recognizing this book on the Ruby on Rails weblog. Hope you all like it.

Testing Practices Interview 7: Mike Gunderloy

2009-07-01T21:50:39-05:00

The Testing Practices Interview series is back. Our interviewee is Mike Gunderloy, publisher of A Fresh Cup and member of the Rails Documentation Team.

Mike has recently released Rails Rescue Handbook, a guide to taking over Rails projects that have been abandoned or are otherwise new to you. It’s a DRM-free PDF file, available for $9.95, and it’s full of useful tips and advice, highly recommended.

So, here’s Mike.

How did you get into writing tests regularly? Did you have a specific moment when you realized automated testing was valuable?

To some extent I’ve been testing for 30 years, ever since I got started programming. I don’t see a strong distinction in purpose between manual testing, debugging, and automated testing: they’re all ways to make sure your code does what you think it does.

As far as automated testing, though, my first exposure was during some Microsoft contracts 10 years ago or thereabouts. But on those big projects, automated tests were maintained by the testers, not by the developers; completely different group of people and tools. I did dabble a bit with tools like TestDriven.NET, but ultimately, it was moving over to Ruby/Rails that got me into a truly test-infected environment.

So I’ve pretty much “always” known that testing was valuable, and even seen the benefits of automated testing for quite a long while. It’s been an evolutionary step from there to developer-written automated tests and TDD – which I am not religious about. I use TDD when it suits me, and skip it when it doesn’t.

What is your Rails testing process? What kinds of tests do you write, and what tools do you use to write them?

Probably 90% of the tests I write these days are functional and unit tests, and the other 10% integration tests. As a subcontractor to many different teams, I’ve had the chance to experiment with a great many tools. The exposure has left me unconvinced that there’s a good ROI on either view testing or Cucumber-style BDD, though I recognize that reasonable people differ on this (and that different teams or different projects might have left me with a different impression).

When I have the luxury of picking my own tools these days, I find myself using Test::Unit, Shoulda, Mocha, and Object Daddy most often, with a side of parallel_test when the test suite grows. I’ve played with a couple of different CI servers as well, and at the moment I’m leaning towards Cerberus.

As far as process goes it’s a mix of TDD and more traditional top-down decomposition development with tests as I go; some of this just reflects my age in the industry, I’m sure. I do lots of little code spikes via git branching, and those usually don’t have tests involved; then I’ll come back to the branch I’m working on when I know where I’m going and write the tests and code together.

What’s the most interesting thing you’ve discovered about testing recently?

I’ve been spending a fair amount of time doing code reviews lately. It astonishes me how many teams – even good teams writing good code – have little to no test coverage. The fact that the code is good indicates that testing is not 100% essential – the fact that it has holes shows how it would help. And it’s also evident that the wider Rails community isn’t as test-infected as we like to think it is.

Is there a tool you wish you had for testing that you don’t think currently exists?

I wouldn’t mind finding a good open source record-and-playback tool to use for browser-based integration and maybe even view testing. That used to be pretty useful, back in the day. For all I know one exists and I haven’t gone looking for it. I’d also like something that could do an automatic “lint” looking for cross-browser issues.

What advice would you give somebody looking to write more effective tests?

0) Buy Noel’s book. 1) Write tests. Like anything else, you improve if you do more of it. 2) Find a project you like and look at their tests to see how they did it. If you find patterns you can steal, go for it.

It's been a while

2009-06-18T14:54:00-05:00

Okay, it’s been a while since I’ve posted here and some things have built up. Here’s what’s going on.

Chicago Ruby Talk

First off, for those of you in and around Chicago, I’ll be presenting at a ChicagoRuby.org meeting downtown on Tuesday, June 23rd at 6:00 PM. Click here for details. The talk will be on the general topic of good testing practices, especially for getting started with testing.

Book Status

I’ve been working through reading the book, making edits, incorporating comments that I got from Dana Jones, making sure everything is up-to-date and that I still agree with everything. It’s been going slowly. I currently expect the next update to be the 29th, rather than the 22nd, but I also hope that will include new sections on Rcov and Webrat.

Twitter

I’ve started posting a testing tip every day (well, not sure about weekends) on the twitter @railsrx account—take a look.

Registration Email

If you’ve registered your book at the railsrx site, and haven’t gotten an return email, try and log in anyway, I’ve probably approved you. We’re having some issues apparently with the response emails getting marked as spam and bouncing, which we’re working on mitigating.

Pathfinder Blog

Over on the Pathfinder blog, I’ve had some testing related posts in the last few weeks:

Rails Testing Frequently Asked Questions — The Non-Code Version

Factory tools for fixture replacement: a comparison

Comparing Ruby Mock Object Libraries

The Return of the Cucumber

Version 005 Now Available

2009-05-25T23:08:54-05:00

This time around we have the following:

Long chapter on RSpec
Messed with the cover some more
Many typos fixed, courtesy of Dana Jones

The RSpec section turned out to be the longest in the book by far, and kind of crowded out anything else I was hoping to get in this iteration.

Big thanks to Dana for catching a lot of typos and places where the text was unclear.

Next time around, it’s looking good for Webrat, among other things.

Update via http://www.railsprescriptions.com/products.

Thanks.

Coming Attractions

2009-05-19T13:18:05-05:00

Here’s what’s up.

The next book update will be next week, either Sunday or Monday, depending on how the holiday weekend goes. The lineup:

New chapter on RSpec. This looks like it’s going to be… thorough. As with pretty much every big-ticket section of this book, I always wind up writing more detail than I originally think I’m going to.

General edit of the book, incorporating some great proofreading notes from Dana Jones and adding references to RSpec in other chapters as needed.

If time permits, I’ll either do a relatively short tool article (rcov is a possibility), or add on to one of the style and rationale pieces.

Those of you who have reported the issue with text search in the book using Apple’s Preview or Skim, which I think both use the same core Mac OS library—I’m trying to track it down. The makers of the PrinceXML software that generates the PDF point to the fact that everything works fine in Adobe Reader and say it’s a Skim problem. The Skim team has been a little harder to track down, but they aren’t convinced. More news when, or if, events warrant. (It does seem like, whoever is at fault, there’s a setting I’m using that’s exposing the bug. Sure wish I knew what it was.)

A Few Good Updates

2009-05-12T23:33:49-05:00

For the rest of this week, I’m answering questions in the forums at Ruby Learning.org—stop by and ask a question if you’ve got one. Posters are eligible to win free copies of the book.

Unsurprisingly, RailsConf was something of a lost week in terms of writing on the book, so I’ve decided to skip a week in the update schedule. The next update will by May 25th, and it will include a new section on RSpec, a new section converting my RailsConf presentation back into text, and something else as time permits. I’m actually hoping to get another edit read on the entire text.

I forgot to mention one of my favorite sessions of RailsConf, the Teaching Rails BoF that was moderated by Ben Scofield. There was a lot of great energy in the room and a number of people working on related efforts. Checkout RailsBridge as well as the Rails Tutor project. Also keep an eye out for a Rails Mentoring program coming online soon.

A Testers Guide To RailsConf 2009

2009-05-10T22:20:45-05:00

Testing was a popular topic at RailsConf this year, with a lot of sessions on various testing tools and a lot of prominent interest in testing process.

Here’s a quick look at the sessions that were interesting from a testing perspective. And also my session, which was from a testing perspective as well. Where applicable, links go to the presentation slides.

Testing, Design, and Refactoring, Jim Weirich and Joe O’Brien.

This was a tutorial session that I caught a tiny piece of. Weirich has a well-deserved reputation for running great training sessions, and this one seemed effective.

Don’t Mock Yourself Out, David Chelimsky

Saw this one. Chelimsky, who is the lead developer of RSpec, gave a nice overview of how to use mock objects, and even better, how to use them well.

He also introduced a couple of new tools. One was stub_chain, a new feature of the RSpec mock framework. The use case here is when you had to create a series of mock objects to cover a long chain of objects. In the old way, you needed to create a bunch of intermediate objects that you didn’t much care about:

  member = stub_model(User)
  friends = stub()
  friend = stub_model(User)
  User.stub(:find).and_return(member)
  member.stub(:friends).and_return(friends)
  friends.stub(:favorite).and_return(friend)

The new way, with stub_chain, is much more direct.

  friend = stub_model(User)
  User.stub_chain(:find, :friends, :favorite).and_return(friend)

In both cases User.find(1).friends.favorite will return friend.

Another new tool is Stubble, an API for easily mocking ActiveRecord objects. Right now it works with RSpec, but Chelimsky hopes that it will work with other frameworks soon. Within a stubbing block, the ActiveRecord class specified has find, save, and the like stubbed out so that it will not need to contact the database.

  stubbing(Registration) do
    post 'create'
    response.should redirect_to(registrations_path)
  end

These tools, along with some other comments at the conference, lead me to think I need to give RSpec another serious try.

In Praise of Non-Fixtured Data, Kevin Barnes

Missed this one.

JavaScript Testing In Rails: Fast, Headless, In-Browser. Pick Any Three. Larry Karnowski, Jason Rudolph

Only caught the tail end of this one. The tool being discussed here is Blue Ridge, which seems to be a composite tool making it easy to use some JavaScript test frameworks together.

Below and Beneath TDD: Test Last Development and Other Real-World Test Patterns Presentation, by Me

This was my talk. It was pretty process heavy and code-light. I’m going to try to work the substance of it into the book sometime over the next few weeks. Anyway, people came, they said nice things, and overall I was pleased with how it went.

Quality Code With Cucumber, Aslak Hellesøy

I didn’t make it to this session, although I heard very good things about it from other attendees (though I did get to briefly meet Aslak during the conference). Cucumber was all over RailsConf, mentioned in several different sessions, it clearly has a lot of momentum as a useful tool.

Using metric_fu to make your Rails Code Better, Jake Scruggs

I only realized when looking at the slides that this was a descendent of the talk that Scruggs gave at last years WindyCityRails conference. It’s a good talk, and metric_fu is a useful tool.

Working Effectively With Legacy Rails Code, Pat Maddox, BJ Clark

Very well done session that had some suggestions that went beyond what I currently have in the book, although they started with similar advice. A couple of their suggestions include:

Silo code by making it a webservice.
Refactor back to what Rails already does.
Make everything a framework. Write micro frameworks.
Use “nice” metaprogramming
Use existing frameworks, then maintenance is somebody else’s problem.
Look for ways to modify code behavior without changing API, like new parameters with default values
Use selenium recordings as a last-ditch way of testing.

Robert Martin

This link is to the video of the talk. This talk is included in the testing roundup because of Martin’s full-throated support of test-driven development as a professional duty. I very much enjoyed this talk, though I’ll freely admit that it was very much a preaching to the choir kind of a thing. (Not only did Martin strongly endorse TDD, but his diagnosis of what killed Smalltalk was very similar to rants I’ve been doing for years. You’ll just have to take my word for that.)

Testing BoF session

After some dancing back and forth over room assignments, I settled in with a couple of dozen other people for a discussion of testing that largely centered around the best way to get started and the best way to get unstuck. I had fun, but then I got to shoot my mouth off for an hour, so that may largely be redundant.

Webrat: Rails Acceptance Testing Evolved, Bryan Helmkamp

Solid session on Webrat that went far enough beyond beginner material that I felt that I learned some useful stuff about using Webrat in either Cucumber or Rails integration tests.

Overall, a very strong and helpful conference, even with just testing sessions counted. I’ll try and get another post up with more personal comments later this week.

Rails Test Prescriptions update version 4

2009-05-03T22:55:00-05:00

Quick notes before I finish getting ready to go to RailsConf:

Rails Test Prescriptions version 4 is now available both at Lulu and at the http://www.railsprescriptions.com/products product download page. If you have purchased the book and are not a registered user, please register at http://www.railsprescriptions.com/users/new.

NOTE: The login button on this page isn’t working, and I won’t be able to fix it for a few hours. Go to the main home page at http://www.railsprescriptions.com and login from there.

New in this version

Complete chapter on Shoulda
Section on working with a legacy project
New cover

Couple of notes

You may notice the file size has dropped quite a bit from the past version, don’t worry, that’s just the new and smaller cover image.
The Lulu front page hasn’t changed (yet), but the cover of the actual PDF has.

Meantime, see you all at RailsConf, I hope that some of you will come to my talk on Tuesday and the Testing BoF on Wednesday, or at least say hi.

Questions: Where To Test Sessions And Roles

2009-05-02T16:06:23-05:00

Questions, I get questions. Well, sometimes I do. Here’s one. And sorry, this should have been posted here a couple of weeks ago.

[In my project] Only admin users are allowed to add users or inactivate them which means among other things that the user must be an admin and logged in.
I struggled for a while with trying to make a unit test work with this and had issues with the fact that there’s no active session while running unit tests. That further revealed that having this logic in the model is problematic too. People posted ways to make this work, but it appears to be frowned upon. Eventually, I just removed this from the model and placed it in the controller and correspondingly moved the test to the users_controller_test.rb.
So, the correct place for this test is the functional test for users from a testing/functionality philosophical standpoint?

Short answer:

I agree with your conclusion. Logic having to do with authentication and access should be tested in the controller test.

Longer answer:

As you correctly note, sessions are not available in the model test environment, which in my experience is a hint and a half from the Rails core team that they really don’t want you doing that. Rails core is never particularly shy about denying or limiting access to things they don’t want you to be able to do easily. That said, it’s not that hard to fake, see the section in the book for testing helpers for an example of how to get session features in a unit test environment.

From a philosophical standpoint, you want to split the access from what is actually the logic in the model. In other words, whether you need to be a logged in admin to get to the add users page is properly a controller test, so is the idea that if you check this box, the the user’s active status changes. However, if changing the users active status triggers other logic in the model, like some kind of activity history or some such, then there should be a model method with a name like “inactivate” and that method should be tested in the model tests.

Next Update and RailsConf

2009-04-29T09:35:35-05:00

News and notes

The next book update will probably be released on Sunday before I head off for RailsConf. Definitely in there will be a longish chapter on Shoulda and a bit on how to handle legacy code. Hopefully one other chapter as yet to be determined.

Speaking of RailsConf, I’ve also gotten a Birds of a Feather session on the schedule. The title is “Testing In Rails, What’s New, What’s Now, and What’s Missing”, and it’ll be at 9 PM Wednesday night in Pavilion 9 – 10. Come by for what I hope will be an interesting discussion of everything new in Rails Testing land.

Also speaking of RailsConf, follow @railsrx or @noelrap on Twitter for news about giveaways. There will be at least two sets, one of which will be based on attendance at my talk, one of which will not. Free books, and some kind of merch for potential winners who already have a license for the book.

Finally, speaking of RailsConf, I’d love to meet anybody who is reading the book or this blog. I’m probably the worst networker in the known universe, but please do come up and say hi if you see me around.