2
\$\begingroup\$

So I'm doing things the BDD way, writing features first, then moving on to writing specs to add more detail to the mix as I move down the layers.

One thing that bothered me, but isn't a big problem, is that when I got to the controller part of the stack, I have calls to the User and Todo model in my controller spec.

Is this okay and normal? Or should I be stubbing these things out?

describe TodosController do
  let(:user) { Factory(:user) }

  describe "post 'create'" do
    lambda {
      post :create
    }.should change(user.todos, :count).by(1)
  end 
end
|improve this question
\$\endgroup\$
  • \$\begingroup\$ FWIW: A number of people have moved away from speccing controller actions to covering them with Cucumber stories. Like: \$\endgroup\$ – Steve Ross Dec 17 '11 at 2:26
1
\$\begingroup\$

It's fine to test how controllers alter models.

|improve this answer
\$\endgroup\$
0
\$\begingroup\$

You SHOULD not stub anything you have no control of, since the later changes of the stuff out of control will make your tests brittle, while you can stub in this case, since you have fully control of the models

|improve this answer
\$\endgroup\$
  • \$\begingroup\$ That's a confusing answer. \$\endgroup\$ – fivetwentysix Dec 7 '11 at 16:33
  • \$\begingroup\$ @fivetwentysix, say, your app is retrieving the Twitter timeline, and you are using Twitter gem to do it. Since you don't have control of Twitter gem, you can not stub it out, imagine the author of Twitter gem decides to change the implementation of the Twitter gem and return JSON instead of XML, your stubbed test will know nothing about it, and keep your tests green, that's false positive, you are fooled by the stub. Correct me if i am wrong, thanks a lot \$\endgroup\$ – leomayleomay Dec 8 '11 at 1:28
  • \$\begingroup\$ That depends entirely on what you're testing. Full-stack integration is just that, and you'd use the Twitter gem. Lower-level testing, you need to mock things you have no control over, precisely because you have no control over them--without that control, you cannot control what's actually being tested. External services are one of mocking's sweet spots: if I'm trying to test my program logic, and not the Twitter gem, I need to supply known data to my code under test. \$\endgroup\$ – Dave Newton Dec 13 '11 at 4:03
0
\$\begingroup\$

Personally I'm not a big fan of mocking if it's possible to test a particular piece of code without it. Mocking takes longer and I find that my tests are generally harder to maintain because any time that something I've mocked changes I have to go and change all of my mocks in all of my tests, or even worse my tests pass and I end up with bugs. I'm sure there are some pure Rubyists out there that will disagree with me but I've done this both ways and don't plan on going back to mocks. One downside to not using mocks that I've found is that my tests are generally slower, because I'm using fully hydrated rails models with callbacks instead of dumb mock objects.

|improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.