fake_for retuning error when not stubbing a void method

17 views
Skip to first unread message

evanh...@gmail.com

unread,
Jul 3, 2016, 4:39:39 PM7/3/16
to Cedar Discussion
I try to use fake_for (or mean fakes) whenever possible, as it gives me the feedback about which methods or properties I'm using that aren't stubbed.  But I find myself wishing at times that Cedar didn't throw an error when I don't stub a void method.  For example I'll have a test that looks like this:

describe(@"LogoutUseCase", ^{

    __block LogoutUseCase *subject;

    __block Storage *storage;


    beforeEach(^{

        id<BSBinder, BSInjector> injector = [InjectorProvider specInjector];


        storage = fake_for([Storage class]);

        [injector bind:[Storage class] toInstance:storage];


        subject = [injector getInstance:[LogoutUseCase class]];

    });


    describe(@"-logout", ^{

        beforeEach(^{

            [subject logout];

        });


        it(@"should clear the storage", ^{

            storage should have_received(@selector(clearStorageData));

        });

    });

});


I would get an error about the un-stubbed method on the Storage class called clearStorageData.  My options are usually to stub the method and return nil, or just turn the object back into a nice_fake_for and keep going.

I would love it if cedar knew not to complain when I don't stub a void method on a fake_for.  Unless you all think it is still valuable to keep the error there, and maybe I can't think of a use case for it.  I'd be interested to hear anyones thoughts.

Thanks!
-Evan

Sam Coward

unread,
Jul 5, 2016, 4:10:57 PM7/5/16
to Cedar Discussion
FWIW, you can just stub(@selector(voidMethod)), that is, you don't need to specify .and_return(nil)

I think adding this nuance would make the behavior of nice vs. strict fakes harder to discover and violate the principle of least surprise.

The intention of strict fakes is to only allow stubbed method calls regardless of signature. It's quite possible that you have many void methods which do all sorts of transactions and the idea with using strict fakes is you don't want your code changing to send these messages without you knowing about it.

--
Sam

--
You received this message because you are subscribed to the Google Groups "Cedar Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cedar-discus...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

evanh...@gmail.com

unread,
Jul 12, 2016, 12:09:29 AM7/12/16
to Cedar Discussion
Thanks for the reply! I understand where your coming from.

I'll try your suggestion, and see how that feels.

-Evan
Reply all
Reply to author
Forward
0 new messages