Zach Dennis wrote: > When I write software for myself I tend to flip flop. Sometimes I am > writing things to learn or play and I don't test.
I did that on a recent small project and I was amazed at how fast I was able to get things done. > Here's another perspective to look at it from. When you write testable > and tested software you spend less time coming back to it to track > down and fix erroneous bugs. There is a much higher risk you will have > to track down and fix erroneous bugs when you don't test (or don't > test well there is a difference). One of the issues that I have had a couple times is that since I am writing the tests and the corresponding code in a serial fashion, sometimes my mind is off tangent and I write a test that is incorrect, I then write the corresponding code to allow the incorrect test to pass. And voila I have given myself confidence that everything is in working order since I tested it, but it is wrong. I believe, that one of the reasons for this is that I am writing too many tests, and because of that the tests start to lose their meaning. The tests become a series of tasks that I hastily try to place a check next to so I can feel I am working efficiently and move on to the next one. I think cutting down on the number of tests I write will allow me to better ensure the tests I have are required and correct. I am beginning to think that if a person checks the code to test code ratio more than once a week they may be testing for the wrong reason. > First thing: do not stub or mock expect the object under test. > > When you're testing a controller do not "stub!" the controller and do > not > "should_receive" the controller. This removes the value you get for > testing > the controller itself. There are exceptions to this rule, and this is > largely > because people violate the use of mixins. That is for another > conversation though. What would you recommend instead? Since the before_filter contains a login_required check I have to stub something to allow the test to be completed. > So when the application gradually becomes more complex do you think > you'll eventually > get to a point and say, "well I need to test this now?". Unfortunately > even if you do > do that when you get to point there's a really good chance you didn't > write the code > for testability, so the barrier to test is much higher, and it's > easier for people to > give in and not test at this point because it's now to difficult to > test, and they can't > spend a long time fixing bad code they've written. Good point. I guess my confusion is to whether testing should exist where there is really no logic. Take an update controller method: @user = User.find(params[:id]) if @user.update_attributes(params[:user) flash[:success] = "..." redirect_to admin_users_url else render :action => :index end Pretty simple stuff. Is it worth 40 lines of test code? That is what I am wondering, because I don't think so. > Testing is not about developer enjoyment. It's about producing high > quality > low bug software in a way that allows you to sustain a consistent > development > pace over the lifetime of the project. I find that the issue with writing more tests than are required is that things become more brittle. One small change results in 10 failed tests and 20 minutes of work to clean up, and that is not enjoyable. I think that writing tests should be enjoyable since that is what it takes for me to keep doing them. > I think you're experiencing growing pains. Adolescence all over again :) Thank you for posting your > concerns and questions. I used to have some of the same questions > you're having. Hopefully > my response has been helpful to raise some counter arguments to your > concerns, Input from experienced people always allows me to look at things from a different angle. Thanks Dennis. -- Posted via http://www.ruby-forum.com/. _______________________________________________ rspec-users mailing list rspec-users@rubyforge.org http://rubyforge.org/mailman/listinfo/rspec-users
