5 ms·

This tutorial is great. One question for experienced Rails folks: I noticed that a lot of the test code seems to be somewhat redundant and not actually testin

This tutorial is great. One question for experienced Rails folks: I noticed that a lot of the test code seems to be somewhat redundant and not actually testing many different paths of execution. E.g. I saw a lot of test cases like this in his examples: it "should be successful" do get :new response.should be_success end it "should have a follower attribute" do @relationship.should respond_to(:follower) end it "should have a followers method" do @user.should respond_to(:followers) end it "should render the home page" do post :create, :micropost => @attr response.should render_template('pages/home') end Writing a unit test that verifies that some object has a new method/attribute that you're about to add to it, or that some request returns a 200 OK, or that some request renders a specific template? It all seems very...boilerplate to me. Is this a common practice?

mhartl 16y ago
This is a good question, and I actually just added a footnote yesterday to address it. The deal is that, when doing test-driven development, you often bounce back and forth between test and application code, like this: it "should be successful" do get :new response.should be_success end Then def new end Next you'd add a test for what the 'new' action actually does, and then get the 'new' action to do it. In a book, interleaving the test and application code like this is rather cumbersome. The real payoff to this approach will be in the upcoming screencast series (http://www.railstutorial.org/screencasts http://www.railstutorial.org/screencasts), which will allow me to interleave the tests and application code much more finely. Together with Autotest continuous testing and Growl notifications, the screencasts will show just how addictive TDD can be. I should probably motivate this practice better in the book, because it is counter-intuitive. In fact, I thought this technique was crazy when I first saw it. (The same goes for TDD in general.) But it's amazing how much easier it is to get started on a method when the first step is "make sure the method is there". Indeed, such tests aren't really designed to make the application better-tested; they're designed to help the programmer stay in the zone. That being said, there probably are some places where such fine-grained tests aren't worth the trouble, or might even be confusing. I'm about to embark on a Rails 3 update of the book, so I'll keep my eye out for tests that should be removed. If you have any suggestions for tests that should be on the chopping block, please let me know (http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback).
- stevenwei 16y ago
  I guess my question is whether that type of testing is worthwhile. It seems to create a lot of brittle test cases where renaming or moving something can cause a bunch of tests to break, creating extra maintenance overhead, while not actually telling you all that much.
  - mhartl 16y ago
    I think people are still figuring this out. You're right that tests sometimes lock down the implementation a bit much. I'll be on the lookout for changing practices and update the tutorial accordingly.
  - mhartl 16y ago
    I've taken a run at this, and I can't find any tests that obviously need to go. In many cases, some tests aren't strictly necessary, but they do make clearer what the code is supposed to do. Indeed, they often bring to mind the maxim from Structure and Interpretation of Computer Programs: Programs should be written for people to read, and only incidentally for machines to execute. (That's a bit of an over-statement, of course, but its spirit is true.) I also reevaluated the code for possible implementation lock-down. It looks like most such cases involve standard REST action names, such as new and show, or other aspects of the application that are unlikely to change. In the end, you'll have to develop a style that works for you. The code presented in the book is based on the style I've developed in my own work and from reading the code of others, but there are as many styles as there are Rails developers. My job is to help get you on the road to finding a style of your own.

mhartl 16y ago

This is a good question, and I actually just added a footnote yesterday to address it. The deal is that, when doing test-driven development, you often bounce back and forth between test and application code, like this: it "should be successful" do get :new response.should be_success end Then def new end Next you'd add a test for what the 'new' action actually does, and then get the 'new' action to do it. In a book, interleaving the test and application code like this is rather cumbersome. The real payoff to this approach will be in the upcoming screencast series (http://www.railstutorial.org/screencasts http://www.railstutorial.org/screencasts), which will allow me to interleave the tests and application code much more finely. Together with Autotest continuous testing and Growl notifications, the screencasts will show just how addictive TDD can be. I should probably motivate this practice better in the book, because it is counter-intuitive. In fact, I thought this technique was crazy when I first saw it. (The same goes for TDD in general.) But it's amazing how much easier it is to get started on a method when the first step is "make sure the method is there". Indeed, such tests aren't really designed to make the application better-tested; they're designed to help the programmer stay in the zone. That being said, there probably are some places where such fine-grained tests aren't worth the trouble, or might even be confusing. I'm about to embark on a Rails 3 update of the book, so I'll keep my eye out for tests that should be removed. If you have any suggestions for tests that should be on the chopping block, please let me know (http://www.railstutorial.org/feedback http://www.railstutorial.org/feedback).

stevenwei 16y ago
I guess my question is whether that type of testing is worthwhile. It seems to create a lot of brittle test cases where renaming or moving something can cause a bunch of tests to break, creating extra maintenance overhead, while not actually telling you all that much.
- mhartl 16y ago
  I think people are still figuring this out. You're right that tests sometimes lock down the implementation a bit much. I'll be on the lookout for changing practices and update the tutorial accordingly.
- mhartl 16y ago
  I've taken a run at this, and I can't find any tests that obviously need to go. In many cases, some tests aren't strictly necessary, but they do make clearer what the code is supposed to do. Indeed, they often bring to mind the maxim from Structure and Interpretation of Computer Programs: Programs should be written for people to read, and only incidentally for machines to execute. (That's a bit of an over-statement, of course, but its spirit is true.) I also reevaluated the code for possible implementation lock-down. It looks like most such cases involve standard REST action names, such as new and show, or other aspects of the application that are unlikely to change. In the end, you'll have to develop a style that works for you. The code presented in the book is based on the style I've developed in my own work and from reading the code of others, but there are as many styles as there are Rails developers. My job is to help get you on the road to finding a style of your own.