This topic is for the [Write a controller spec] exercise in the [Testing Fundamentals] trail. Post any questions, corrections, or pointers you have to share with other Upcase subscribers.
[Write a controller spec]: https://exercises.upcase.com/exercises/testing-fundamentals-write-a-controller-spec
[Testing Fundamentals]: Introduction to Ruby Tests | Learn RSpec | Testing Fundamentals
Iâm very new to doubles/mocks/stubs, but my understanding is that a mock object is to be a simple, stand-in object that prevents us from have to hit the database, pass validations, and all the other complexities associated with creating a real object. We can then stub the mock with only the behavior we need in the test.
In this exercise, we are encouraged first to write passing tests using real Person objects, and then to improve the tests by using doubles. âOnce you get this test working, try using test doubles so that you donât depend on the actual validations in Person.â
This confused me at first because in this particular case, the functionality we are testing is the creation of an object. When we create a mock, havenât we already done that?
Finding no suitable answer on my own, I submitted my solution with passing tests, albeit using real objects like so:
post :create, person: { first_name: "Tom" }
expect(response).to redirect_to person_path(assigns(:person))
Once I gained access to viewing otherâs solutions, I immediately checked the Upcase featured solution, which was submitted by @croaky. To my surprise, his solution uses the actual objects just like mine does. So far, three people have commented on this, asking why there is not an illustration of mock-style solution, but there has been no answer.
As I clicked through other solutions submitted by various users, I came across only a couple that had a solution using mocks, but those seemed quite verbose and I was not at all confident that this was âthe right wayâ to do it.
In summary, could someone from thoughtbot please address this? Thank you!
@benorenstein @Joshua_Clayton
1 Like
Another point about this exercise - the spec says that when the person is invalid, the controller âredirects to #newâ. I think itâs supposed to say that it ârenders the ânewâ templateâ.
@joshukraine thanks for pointing this out. Hereâs what I came up with: https://exercises.upcase.com/exercises/testing-fundamentals-write-a-controller-spec/solutions/joshuaclayton
This still leverages the Person object, but stubs out Person.new to return the correct instance, then stubs save (avoiding DB calls) and returns a predetermined value, either true or false to test the branch. This guarantees that Person can grow in complexity (validations or otherwise) largely without impacting the controller, which is exactly the isolation weâre looking for in the controller.
Imagine if, every time we modified Person, we had to subsequently ensure that the correct params were being passed in these specs; tests would become a nightmare to maintain! This allows us to sleep easily knowing theyâre decoupled at the unit level.
1 Like
Thanks Andy. Iâve pushed a fix for this.
Wonderful, thanks for the explanation! Would you mind also commenting on the benefit of using Person.new.tap as opposed to just Person.new? The tap method is new to me, and although I did some reading up on it this morning, Iâd love to hear your take as well.
2 Likes
Second question: when I pulled down the git repo for the final step of this trail (testing-fundamentals-write-a-feature-with-tests), I noticed that it also includes a mock solution:
person = Person.create(first_name: "Bob")
allow(person).to receive(:save).and_return(true)
allow(Person).to receive(:new).
with(first_name: "Bob").
and_return(person)
As you can see, this version actually calls create on Person. My initial understanding was that this would hit the database immediately. (It does in the console.) But given that weâre also stubbing out save and new, Iâm assuming that it doesnât. But I honestly donât understand why it doesnât. Is it because this is all occurring inside an it block?
In summary, could you please comment on Person.new.tap vs Person.new vs Person.create in the context of object doubles? Thanks! 
I came up with the same solution and have the same questions. Rspec mocking/stubbing is still mysterious to me, and the documentation is a bit opaque to me. The syntax changes across various Rspec versions donât help, either. Is there a tutorial article somewhere (Thoughtbot maybe?) that actually explains the underlying concepts?
Actually, the second testing trail covers this very topic! Test Doubles | RSpec Stub Online Tutorial by thoughtbot I havenât been through it yet, but itâs next on my list. Hope that helps!
Iâll check it out, thanks.
Yeah, this is a little confusing.
Heres whatâs going on.
# Make a person to use in the test.
person = Person.create(first_name: "Bob")
# If we call save on this person, just return true
allow(person).to receive(:save).and_return(true)
# If someone calls Person.new(first_name: "Bob"), then return the person
# that we created above. DON'T actually return a new person. We're
# stubbing the result of the call to Person.new.
allow(Person).to receive(:new).
with(first_name: "Bob").
and_return(person)
Does that make sense?
2 Likes
I also found this difficult when I started writing controller specs.
If you try use a plain double, you quickly run into problems, because Rails queries the object to discover its type, since it needs that for routing. So you end up stubbing a lot of things that you canât control, which violates the guideline of âDonât mock what you donât ownâ.
The approach that Ben shows above is often called a âpartial doubleâ.
In the past, rspec-rails had the methods mock_model and stub_model, which were useful in this situation. These have now been moved to an separate gem, rspec-activemodel-mocks. Iâm not sure whether to take that as a sign that their use is discouraged by the RSpec team.
Another option is to use build_stubbed from FactoryGirl: Use Factory Girlâs build_stubbed for a Faster Test Suite.
1 Like
@benorenstein Thanks for the explanation. I think my primary point of confusion revolves around what happens when we call create on an object. My understanding heretofore has been that calling Object.create was equivalent to calling Object.new followed by Object.save. In other cases (like @joshuaclaytonâs solution further up in this thread) this is how itâs done.
So I think whatâs throwing me is this: how can we can we first call Object.create and then later stub the save method? Wasnât save already invoked?
Sorry if Iâm missing something obvious here. Just trying to make sure I understand this. Perhaps I should go ahead and dive into the test doubles trail, then see what questions I have there. 
In any case, thanks for the help!
Yes, save was already invoked, but thatâs okay.
The goal is to avoid actually using save in the controller code. Itâs okay that we use it to create some test data beforehand.
So yes, weâve already invoked save in the setup phase of the test, but thatâs not the bit we care about stubbing out. Itâs the save call in the controller that we want to avoid.
Making sense yet? If not, letâs jump on a Skype call next week.
1 Like
@benorenstein Thanks for the info. I still have some questions, but I think at this point it might be better for me to go ahead and work through the Test Doubles trail first. After that, if I still have questions, I may take you up on the Skype idea. Much appreciated!
This is a helpful explanation that, I think, lead me in the write direction https://exercises.upcase.com/exercises/testing-fundamentals-write-a-controller-spec/solutions/equivalentideas .
The mocking stage of this stage was really confusing and I donât think I understand it still. I think this exercise would benefit from more explanation.
Thanks 
Agreed. Itâs on my list of things to tweak.
So Iâm also very new to stubs and doubles. Your answer was a great explanation. Let me see if I get this straight: The purpose of doubles and stubs is to create a quick mock Model object so that in the test env you donât have to make actual DB queries that may slow the test suite down. You are actually only testing the controller for controller-like behavior so it wonât fail if there is a problem with the db or in a model. Am I correct?
Thatâs roughly correct, yes.
But my motivation is less about performance or not hitting the database in case it breaks, and more because I want to test the individual pieces of my system in isolation when unit testing.
Wouldnât something like this work?
person = double('person')
person.stub(:first_name) { "Bob" }
person.stub(:save) { true }
allow(Person).to receive(:new) { person }