← Back to Upcase

Stubs, Mocks, Spies, and Fakes

(Geoff Harcourt) #21

FactoryGirl is great when you really need to touch the database. I find that testing ActiveRecord model scopes with stubs or mocks is awkward (due to the number of intermediary objects created between the scope and the final collection of objects you get back), so if I were going to test a scope like Post.current, I would do that by creating some Posts that I expect to be included and some that I expect to be excluded (all with FactoryGirl), and then I’d test the .current scope and check that the query’s filters worked as expected.

(Nikola Novakovic) #22

Yeah generally I think mocks / stubs is a different thing then a fixture/factory girl. We mostly use mocks/stubs for creating things that are, as Ben said collaborators for the thing we are trying to test.
i.e. If I am testing a user model and for that I need users firm and some other thing I would mock those out. Also that does not mean that you can not use fixtures/factory girl in the same test with mocks and stubs.

(Glenn Espinosa) #23

Is it good practice to generally rely on spies over mocks?

(Nikola Novakovic) #24

It really depends on the preference at the end of the day when you look at spies vs mocks. In my case spies are more readable.

(Yanik Jayaram) #25

Hi guys, I had a couple questions I was hoping you could answer?

  1. “Fakes are a solution to having too many mocks and stubs” - But if you do create a fake, then it seems like a a couple of problems arise. First, you know have to set up a fake test class which needs to be maintained as the class it is faking changes. Second, if your tests are using a fake class, it seems like what your testing is a fake class, and not the real class, which is supposed to be the recipient of these tests.

  2. In your CommentNotifier test, you guys had a line in the “allow” clause that allowed an object to receive a method “WITH” another object. Was that “with” really necessary? It seems like all that mattered in that test was that the initialization method returned a notification object.

  3. You guys mentioned that too many stubs means you may need to remove collaborators or set up a delegator or something called a ‘facade’. Could you please give a simple example of how those three different things would work?

Thank you!!

(Jared Galanis) #26

@jferris I’m a little confused about how solution is being accessed from Participation if the stub is allowing clone to receive solution. Is this is just occurring through some principle of inheritance (i.e. because clone is a property on Participation)?