I’ll keep this short and sweet.

Rails Test Prescriptions is now on sale.

The Lulu URL is http://www.lulu.com/content/e-book/rails_test_prescriptions/6418439. Price is $9.00. Please let me know what your purchase experience is like—and keep the Lulu receipt. I might use it for update registration in the future.

I hope you like what’s there and what will be coming. Please email at railsprescriptions at gmail dot com, or use the Get Satisfaction feedback link, or comment here. Your feedback will make a huge difference in how this project proceeds.

Also, I feel a little silly mentioning this, but I also feel silly not mentioning it. If, for some reason, you feel like supporting this project beyond purchasing a copy—like, you want to distribute the book throughout your organization, there’s a PayPal donate link on this site. Funds will go toward improving the book and this site.

Thanks for all your support and kind words over the last few months.

Sorry about the Radio silence here for the last week. Let me make it up to you with a site update including a slight change in what we might generously call the Rails Prescription business model.

The comments on this post rattled around with a nagging thought in my head. I had been starting to worry whether the recipe-style format I’ve been writing in would have a decent entry point for a reader who was a near-total novice at testing. In conjunction with the comments on caboo.se and some feedback I’ve gotten, I decided to stop the part of the book I was working on and start working on a new tutorial for getting started with test-driven development practices.

I’ll be giving the tutorial away free on this site staring sometime in early January—I have to finish the writing, and I want to make some site changes to support distributing content.

The tutorial takes a reasonably real application, and walks through the first few feature additions, showing all the tests and the code the makes them pass, with a lot of discussion on why particular tests were written and others were not. It’ll include controller tests, model tests, view tests, tests with RESTful authentication in play, and I’m not sure what all else yet because I haven’t finished it. Mostly, I’m really writing this application but just taking some detailed notes on how I’m testing it.

I’ll be distributing the source code as a git repository with numerous branches corresponding to different points in the tutorial so you should be able to recreate the exact state of the application to help see what’s going on.

This works for me because I was looking for a convenient chunk of the book to use as free content, and because it gives me a chance to get feedback on overall tone, PDF layout, and so on.

This works for you because hey, free content! It’ll be a great place to get started with test-driven development.

I completely agree with this blog post about testing, and I second the observation that there seem to be a lot of Rails programmers out there not testing.

At Pathfinder, we’ve been asked to take over several preexisting projects that have little or no testing. Asking about test experience is a core piece of our Rails interview process, and I’d say that more than half of our interviews over the past year have no testing experience and turned in a code sample with no tests.

I thought the comments were interesting, but basically broke down into a) I don’t know what to test, and b) the test process breaks my flow.

That’s understandable—I think that the groove you get into when you do test-driven development right is a deep one, and you can definitely get into a nice flow with TDD.

But it’s a narrow groove, it’s not hard to have a bad experience. In fact, if you make your test/code run loop too long, you’re almost guaranteed a bad experience. Tests get much harder to write the longer that the code has sat without tests.

Some representative quotes from the comments to that post, with my thoughts:

“I honestly don’t know what and when to test”

It’s a tough issue, especially with a framework like Rails that does so much on it’s own. My feeling is you don’t need to test anything that Rails is doing (in theory, that’s covered by Rails own tests). Everything else in your code, though, is fair game.

“I Feel that testing breaks ‘flow’”

This is not my experience. At least in web programming, I find that the alternative process of write a little bit of code then try and test it in the browser is much more disruptive than getting the code right with tests, then validating in the browser. Obviously, though, I can’t speak to your own flow.

“But I haven’t found any tutorials or resources that adequately break it down for a total beginner”

Hopefully, I’ll have that out to you shortly. Still, this is a problem. Most technical books are too focused on the actual content to cover tests, and test-only tutorials tend to be separated from context. In the interim, can I humbly suggest my Professional Ruby on Rails? I tried to make as many of the examples as possible have tests written first. You might find that helpful.

“If you’re not already doing it, it never seems like you have the time to learn it before you’re back operating smoothly again.”

Yeah, that’s the good-old productivity paradox, where the people who could most benefit from productivity improvements don’t even have the time to learn the improvements. I don’t have an answer for that one yet.

“Because testing right is hard. Because it’s something that might save your bacon one day, but doesn’t give instant gratification like learning a new programming language. Because it just takes so damn long for me to write tests, time that I feel could have been better spent somewhere else afterwards.”

If you’re taking so long to write tests that it’s interfering with your process that much, then you’re probably either trying to test too much, or letting your test/code/test loop get too long. It’s a little counterintuitive, but it really does make a difference—writing shorter tests then quick code to make it pass really does go pretty quickly.

In some ways testing via test-first is hard, especially if you aren’t used to it. It’s hard to get the rhythm of it down, and really learn to trust the process. But when you get there, going test-driven really does speed things up and help break complex problems into simple parts.

So, I’ve decided to write a book about testing. Which begs the question: what goes in a book about testing?

I decided almost immediately to use a format with a series of short sections, somewhat along the lines of a recipe or hacks book. A full-on narrative book following a single site would be hard to do for testing—you’d wind up bringing in all kinds of details about the site being built that would distract from the test content.

I’ve never done anything in a recipe-esque style, and I like the idea that it’s a flexible format that would be easy to expand and keep curent over time. In case I haven’t mentioned it enough times, the goal here is to keep this book from decaying—a short-section format enables that somewhat.

Having decided on that format, the “prescriptions” name came out of a thesaurus search on “recipes” to try and come up with a word that seemed suitable. I liked the health metaphor, so—name chosen. One of these days I need to register the domain for the obvious misspelling…

My own experience as a connoisseur of several recipe books is that they can be pretty hit and miss. Typically, there are some recipes that are indispensable, some others that I already know, and some that are specific and don’t apply to me. Done well, it’s worth the time and effort. Not done well, and you feel like you’ve bought a $30 dollar book for $9 of content. (I’m hoping that offering my book for $9 will mitigate this complaint somewhat…)

This begs a number of related questions. Aim the book at a beginning user, intermediate, or advanced? Focus on Shoulda or RSpec? Obviously, any decision here has an impact on who will find this book useful.

For the user question, I tried some basic user modeling and profiling techniques, ending up with the following two (oversimplified) groups that I want to satisfy.

• Beginner to intermediate programmers who know Rails, but haven’t done much testing. If the code samples I see in resumes and projects we take over is any indication, there are rather a lot of you. These readers don’t need me to define Rails concepts, but they probably would like to have a description of what testing tools are available, how to use them, and most importantly, why to use them.

• Intermediate to advanced programmers who already do testing, but are looking for a single point of reference for testing tools. These programmers probably are looking for the book to be a guide to testing some more specific cases, like, say, file uploads, they also want plain reference material, and stuff that will help persuade recalcitrant colleagues might be nice.

How to balance these? What I’m trying to do is make sure that the “basic” prescriptions, like “I need to test models” will have enough reference material to make them useful for advanced users, while making the “advanced” prescriptions something that the beginner users will be able to use as needed.

As for tools, I think this one might change over time (perhaps due to feedback from potential readers…), but the current guidelines are:

• By default, use the base Rails test facilities. The 2.2 update was helpful here in that it closed some of the gap between base Rails and RSpec/Shoulda

• Any test framework that has a significant user base will get one prescription just on how to install and use it.

• Where one of the external frameworks offers a feature that’s not in the base test set, that feature will be covered where appropriate—so RSpec’s view testing setup will be included as part of the section on view testing, Shoulda contexts are discussed in a style section on grouping setups, and so on.

I’m hoping this set of guidelines will make the book as useful as possible for as many of you as I can. But one reason for starting to talk about the book now is to get feedback about these choices while there’s still time for me to do something about it.

I’d like to read a brief statement, and then I’ll take a few questions.

Today I’m happy to announce the grand opening of Rails Prescriptions, a purveyor of fine Ruby on Rails books and book-like products.

The first book from Rails Prescriptions will be titled Rails Test Prescriptions: Keeping your application healthy, and will be available for order in January, 2009.

Rails Test Prescriptions is a comprehensive guide to automated testing for your Rails application, containing more than 30 individual prescriptions on various Rails testing features and techniques. I’ll be continually updating the book after its initial release to allow for changes in Rails, new testing tools, correction of the occasional error, and reader feedback. I want this book to stay in date as long is it has readers.

And now, your questions. I’m guessing:

What format will the book be released in?

The book will be a DRM-free PDF file. Additional formats (like a print-on-demand version) may be offered if there’s an outcry.

How long will the book be?

Not sure how meaningful this is because the page formatting is optimized for screen, but the PDF will probably wind up being around 200 pages give or take a couple dozen.

What’s the schedule and pricing?

The final book will probably be $9, and will be available sometime towards the end of January, 2009. Free samples will most likely pop up by the end of 2008 or so, and there will be a chance to buy a beta/incomplete version earlier in January, probably at some discount. But I haven’t decided on that for sure.

Once you’ve bought the book, you’ll be able to get free updates regularly for some extended period of time. I really want this book to stay up to date and useful.

January is like, weeks in the future. Why announce it now?

Because I want to hear from potential readers now. I have an outline with about 30 potential sections. But I want to know what’s important to the people that might actually buy this book. What tools would you like to see documented. What part of Rails do you find hard to test? Generally, what would make a book on Rails testing something you would actually use to make your work easier?

How can I make suggestions?

The two best ways are to email to railsprescriptions at gmail.com or head over to our Get Satisfaction link at http://getsatisfaction.com/railsprescriptions. You can also direct message me on twitter.

How can I follow the Rails Prescriptions news?

Subscribe to the Rails Prescriptions 24 Hour Window blog. Also, I’ll be updating via twitter, follow me there.

How far along is it?

Something like 30% of the first draft complete at this point.

Why this book, this way, this time?

Well here’s a funny story. I started pitching a (different) Rails book to publishers, a process that started in June ‘08, and resulted in a tentative offer toward the end of October. That required me to turn in the book in April ‘09 for publication in August ‘09. That’s a long time, especially since there’s no easy way to keep a major-publisher book up to date.

So, I thought, I can do this myself and get it out in front of people a whole lot faster than 14 months. And I could keep the book up-to-date. And choose my own tools and layout. Suddenly this started to sound like a lot of fun.

Having decided to distribute my own book, it seemed like a book on testing would be a bit more fun to start with than my original plan. (If things go well, some form of the original book will be the second Rails Prescriptions title).

Sounds great. Now what?

Thanks for reading this far. Check out the Rails Presciptions blog and the twitter feed, and watch this space for more info.