---------------------------------------- > Date: Wed, 2 Jul 2008 06:15:10 -0500 > From: [EMAIL PROTECTED] > To: [email protected] > Subject: Re: [rspec-users] Stopping Example Execution? > > On Mon, Jun 30, 2008 at 5:11 PM, Britt Mileshosky > 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
Yep, thats exactly what I've been practicing, and while its not exactly what I want, it does work nicely. Thank you David _________________________________________________________________ The i’m Talkaton. Can 30-days of conversation change the world? http://www.imtalkathon.com/?source=EML_WLH_Talkathon_ChangeWorld _______________________________________________ rspec-users mailing list [email protected] http://rubyforge.org/mailman/listinfo/rspec-users
