On Mon, Jun 30, 2008 at 5:11 PM, Britt Mileshosky <[EMAIL PROTECTED]> wrote: > > n Sun, Jun 29, 2008 at 12:20 PM, David Chelimsky wrote: > On Jun 29, 2008, at 11:18 AM, Britt Mileshosky wrote: > > However, do you see where something like a return statement or end example > statement could be beneficial? > If you are working from the top down with your controller action execution, > then you only need to test your expectation > and then bail out of your action. No need to further test or meet > requirements on anything else in that action because your > single test has been met. > > - in my example for making sure I find a user, I'd like to end execution once > I DID find the user, i shouldn't have to satisfy > requirements about finding an account and a person... I'll write those > expectations later in another nested describe group, as you > can see here, in a top down process > > PeopleController with a logged in user > - should find user > > PeopleController with a logged in user who has an account > - should find account > > PeopleController with a logged in user who doesnt have an account > - shouldn't find account > - should redirect ... > > PeopleController with a logged in user who has an account the person belongs > to > - should find person > - should assign person for the view > > PeopleController with a logged in user who has an account the requested > person does not belong to > - should not find person > - should ... > > My instinct about this is that it would encourage long methods because it > would make it less painful to test them, so I would be adverse to anything > that let's you short circuit the method. > > Anybody else have opinions on that? > > > > I'm just catching up on email now after being sick for the past six days, but > health aside my opinion is that I agree with David's opinion. Rather than > focusing on how-to write easier tests that complain less, start focusing on > how-to write the right tests that complain when necessary. > > One of the benefits associated with feeling the pain of a test is that it may > be a sign to re-assess and refactor your code. This usually happens early > enough that it only takes a few minutes. Short circuiting essentially gives > you the ability to not feel the pain. Its like CIPA [0], but for code. I > would fear that the code would get so bad that by the time the test cried > with pain your code was already beyond easy repair and instead required > invasive surgery. > > Tests are part of the nervous system of your application. When they hurt, > they're telling you something isn't right and that it should be addressed, > > > > I wouldn't really say that anything I have been presenting has been a result > of 'pains', > more so an observation on how an example group with other example groups can > be much more readable > for myself and for other developers when they need to read the specs. > Stubbing everything at the top doesn't > make complete sense. Why not stub inside the example group that has a NICE > describe statement telling you > what this stubbing is related to. We can't do this because the first examples > will blow up due to having to execute > all the code. > > Take the 2 examples: > > ------------------------------------------------------------------------------------------------------------------------ > PeopleController > # stub everything way up here at the top where these > # definitions are out of context (by means of position) with following > examples > # > # stub controller requirments > # stub logged in requirement > # stub account requirement > # stub no account requirement > # stub account owns person > # stub account doesn't own person > > > PeopleController with before filters > - should require user > > PeopleController with a logged in user > - should find user > > PeopleController with a logged in user who has an account > - should find account > > PeopleController with a logged in user who doesnt have an account > - shouldn't find account > - should redirect ... > > PeopleController with a logged in user who has an account the person belongs > to > - should find person > - should assign person for the view > > PeopleController with a logged in user who has an account the requested > person does not belong to > - should not find person > - should ... > > ------------------------------------------------------------------------------------------------------------------------ > PeopleController > # stub the minimum needed to get to the first example group up and running > > PeopleController with before filters > - should require user > > PeopleController with a logged in user > # stub logged in requirement > - should find user > > PeopleController with a logged in user who has an account > # stub account requirement > - should find account > > PeopleController with a logged in user who doesnt have an account > # stub no account requirement > - shouldn't find account > - should redirect ... > > PeopleController with a logged in user who has an account the person belongs > to > # stub account owns person > - should find person > - should assign person for the view > > PeopleController with a logged in user who has an account the requested > person does not belong to > # stub account doesn't own person > - should not find person > - should ... > > ------------------------------------------------------------------------------------------------------------------------ > > I prefer the second group, but unfortunately I am not able to write my specs > in this organized fashion. > Just sayin.
I appreciate the communication value you're looking for, and you can get it by stubbing everything you need to keep execution going before(:each) example and then set message expectations (should_receive) inside each example that help tell the story of that example. PeopleController # stub everything way up here at the top where these # definitions are out of context (by means of position) with following examples # # stub controller requirments # stub logged in requirement # stub account requirement # stub no account requirement # stub account owns person # stub account doesn't own person PeopleController with before filters - should require user PeopleController with a logged in user # expect logged in query - should find user PeopleController with a logged in user who has an account # expect logged in query # expect account query - should find account etc HTH, David > > Britt _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
