small medium large xlarge

20 Apr 2010, 22:08
Christoph Jasinski (9 posts)

First, I really appreciate that the tests are done in each chapter of the depot application and not in a huge ‘never-to-be-dealt-with-chapter’ at the end.

=> But what I don’t understand is why do you stick with Test::Unit, although that’s no longer the ‘best practice’ and it’s more difficult than RSpec and cucumber (as example). Wouldn’t it be easier for beginner to use those two instead of Test::Unit?

=> Secondly, why isn’t the application build with the TDD or BDD technique to (again) teach people good software practice?

=> Thirdly: Fixtures???.

My questions might sound stupid, but from my industry and university experience I got this: - testing is non-sense - nobody I know made it through the ‘test chapter’ (in earlier edition). Me too.

Took me a lot of time to find it all out (TDD, BDD, RSpec, Cucumber, Test::Unit etc.). If I would have learn Ruby or Rails development with TDD/BDD right from the beginning, it would spare me lots of pain.


21 Apr 2010, 01:29
Sam Ruby (633 posts)

Everybody has an opinion on what is best practice. For example, I’m personally partial to JQuery.

The focus of Part II is on the “golden path”. In other words, it isn’t about what I prefer, it is about the defaults the Rails team has chosen for you.

The answer to your second question is a bit more subtle. This isn’t a book on TDD or BDD. Doing that right would require that over half of the book would be on the topic of writing good tests. That would be a different book. The focus of this book is on Rails.

Meanwhile, there is a section on unit testing. There is a section on functional testing. And in the next beta, there will be a section on integration testing. As you note, these sections are more strategically placed so that they will be read.

That’s the current thinking. Feedback welcome.

21 Apr 2010, 20:57
Bill Turner (1 post)

I’m very, very happy to see Testing more integrated into the chapters/book. With 1st & 2nd editions (never bought third) I skipped the testing chapter and now wish I didn’t. Playing catch-up is never fun.

Now, I only wish there were a way to get a discount on the newer editions if you bought older ones. :)

07 May 2010, 08:45
Martin Hawkins (5 posts)

Like many people, in my rush to get started I skipped the section on testing in the earlier versions and am now playing catch up. (I’ve bought the Rspec book).

I think Sam is right - the book is about Rails, not testing and I think the new approach is sensible.

08 May 2010, 06:06
Manuel E Vidaurre Arenas (8 posts)

IMHO the book is about Rails but it should be shown also the state of the practice for doing the best. As I mentioned in several of my errata/suggestion reports, TDD/BDD are an essential part of the current best practices for Rails development. For example el use of cucumber for leading Rails shops. As I mentioned the Test First in TDD/BDD actually are more about to define the desired behavior written the failing test using The Code You Wish You Had this will provide you with an emerging design. Usually this is better if you use an outside-in approach where Business Value drives the development. Then you code The Code You Wish You Had to pass the test/scenarios and refactor and pass the test/scenario. Because in this context the testing word usually generates confusion that is one of the reasons for changing terminology in BDD. Maybe a more balanced approach taking in consideration that will be better IMHO specially for beginners. As Bob Martin mention, in the early days of medical quirurgical practice washing the hands before an intervention was considered a lose of time. Kent Beck in “Test-Driven Development by Example” mention: “I taught Bethany, my oldest daughter, TDD as her first programming style when she was about age 12. She thinks you can’t type in code unless there is a broken test. The rest of us have to muddle through reminding ourselves to write the tests.”

08 May 2010, 14:00
Sam Ruby (633 posts)

Manuel: thanks for posting here! (Errata turns out not to be a great place to have a back and forth discussion).

As I mentioned above, I personally prefer JQuery over Prototype. Yehuda prefers DataMapper over ActiveRecord. You prefer Cucumber over test/unit. At least one Rails core developer prefers rip over bundler. Any number of people prefer MySQL over SQLite. Many prefer haml over erb, sinatra over actionpack. Mercurial vs Git. The list goes on and on.

Each can make a solid case that what they are doing is “the state of the practice for doing the best”. An example of feedback I’ve gotten: “who in their right mind would develop and test with one database engine and then deploy with another?”

I need to have some overall plan over deciding what to cover and what not to cover. The plan I settled on was simple: if it is in the package of what you get when you gem install rails, I cover it. If not, I leave it to part III.

Exceptions to that: I want to cover the concept of plugins, so I picked exactly one (will_paginate). The deployment chapter (which you should be seeing shortly) follows the recommendations of the Rails team, and further shows that the database can be replaced, and picks MySQL (undoubtedly much to the disappointment of PostgreSQL fans). I’m also not planning on covering ActiveResource in Part II in this edition, even though it clearly is a part of the base package, simply because I’m not convinced that it is something you have gotta know before you proceed.

But back to the topic at hand: I’m letting the Rails core team decide what is the state of the practice for doing the best, and focusing on covering what they select. Rails 3 is certainly a major upgrade, and they could have decided to rip test/unit out, make it a plugin for those that want it, and replace it with Cucumber/RSpec. And it is not too late: you are welcome to convince them to do so, and if they do, I will update the book to match. But meanwhile, my plan is to continue to track what they include.

Secondly, I will note that I barely scratch the surface of testing (or of active record or of any number of topics) in Part II. If you look closely, you will see that most of the new functionality isn’t getting a proper test. My goal with Part II is to introduce them to the concepts, with a minimum of repetition. There are a lot of concepts introduced in Part II, and if each were preceded by a test, that would greatly expand the book, and yet not manage to add much in the way of coverage of additional topics.

Finally, I will say that while I haven’t read it, I have taken a peek at Rails Test Prescriptions, and that might be just the book you are looking for. I’m going to try to get in contact with the author of that book and see if he has any suggestions.

14 Feb 2011, 15:06
Benjamin Unger (4 posts)

Sam, thanks for your great book. I have little programing background and started learning rails in earnest on 1/1/11. Yours is the second tutorial I’m exploring after Hartl’s excellent Rails Tutorial. Despite my inexperience programing, it seems clear that one cannot program robust and scalable apps without TDD. Having been exposed to Rspec, however, I can’t go back to using Test::Unit. It’s awkward even to my inexperienced eyes. I hope to use rspec wherever you use Test::Unit.

I’ve reproduced my products_controller_spec.rb (for the file on page 99, depot_c/test/functional/products_controller_test.rb) below in case anyone wants to take a look or use it themselves. It is awkward, newbie horrible including the remnants of my desperate exploration of Factories to try to make the specs work. It turns out – I think – that I needed an example with a different title to comply with the validations. Also, I didn’t understand what Test::unit was doing with “@product = products(:one)” which I assumed was something unique to the Test:Unit setup requirements. In my rspec file I replaced it with “@product =”


require ‘spec_helper’

describe ProductsController do

before(:each) do @product = @update = Factory(:product) @attr = { :title => ‘Book on Ruby’, :description => ‘Wibbles are fun!’, :image_url => ‘lorem.jpg’, :price => 19.95 } end

it “should get index” do get :index response.should be_success assigns[:products].should_not be_nil end

it “should get new” do get :new response.should be_success end

it “should create product” do expect { post :create, :product => @attr
}.to change { Product.count }.by(1) response.should redirect_to(product_path(assigns(:product))) end

# …

it “should show product” do get :show, :id => @update
response.should be_success end

it “should get edit” do get :edit, :id => @update response.should be_success end

it “should update product” do put :update, :id => @update, :product => @attr response.should redirect_to(product_path(assigns(:product))) end

# …

it “should destroy product” do expect { post :destroy, :id => @update
}.to change { Product.count }.by(-1)

response.should redirect_to(products_path)   end


21 Feb 2011, 03:43
Steve Castaneda (11 posts)

Doesn’t the 37 signals team using Test::Unit for testing for their suite of products? I swear I read a comment by DHH on that fairly recently.

You must be logged in to comment