On Fri, Mar 14, 2008 at 2:08 PM, __iso __ <[EMAIL PROTECTED]> wrote:
> 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.
>
I typically test filters by themselves, and then stub out the filters
when testing the action, so there is a clear separation between the
two. For logins I use a helper to ensure that a controller/action is
requiring login if necessary.
describe SomeController, "#index" do
it_requires_login :get, :index
end
Then when testing the action itself I do stub all before filters,
because I have already tested them elsewhere. If the action requires
login I have a login_with_user helper which sets the logged in user to
some mock User and then returns it so I can use it in my test. LIke
below:
describe SomeController, '#index" do
def get_index
get :index
end
before do
stub_before_filters!
@user = login_with_a_user
end
...
end
>
> > 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.
Can someone change this implementation and still have your tests pass,
but have the implementation be broken? If they can then yes it is
worth the 40 lines.
Pat mentioned that he uses very skinny controllers and does
integration tests which go through the whole stack to make sure things
work. So if he doesn't test the controller#action's because they are
too simple he at least will have a failing integration test if someone
breaks the implementation.
The problem I have with what Pat is doing is that it takes a lot of
discipline from the developer to not let the controller grow into a
cesspool of logic and interaction that shouldn't be there, but you put
it there because you aren't "testing" it directly. From what I've seen
most Rails apps have important interaction in the controller actions
and logic in the before filters. I would not personally take this
approach on customer paid for software. Pat may be more disciplined
then me though. =)
> > 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.
If a change to one object results in multiple failing integration
tests, then that is awesome because you know exactly what you broke
with that change. If that change breaks a bunch of model, controller,
etc specs then how there is an issue in how you're testing.
> I think
> that writing tests should be enjoyable since that is what it takes for
> me to keep doing them.
Testing is a skill to be learned. I get a lot of enjoyment out of
producing high quality software for my customers. Testing reinforces
that I do just that. I also get enjoyment out of finding better ways
to write software which makes them more easily testable. If you're
looking for the instantaneous gratification that you get with hacking
something together real quick then you're not going to find that with
testing. If that's your motive for writing tests then you're writing
tests for the wrong reasons.
>
> > 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.
>
>
Dennis my last name. Zach is my first name ;)
--
Zach Dennis
http://www.continuousthinking.com
_______________________________________________
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
