[rspec-users] Stopping Example Execution?

David Chelimsky dchelimsky at gmail.com
Wed Jul 2 07:15:10 EDT 2008


On Mon, Jun 30, 2008 at 5:11 PM, Britt Mileshosky
<mileshosky at hotmail.com> 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


More information about the rspec-users mailing list