# Is it possible to test controllers without calling views?

**URL:** <https://www.ruby-forum.com/t/is-it-possible-to-test-controllers-without-calling-views/146242>\
**Category:** Rails\
**Created:** [August 19, 2008, 12:34pm UTC](https://www.ruby-forum.com/t/is-it-possible-to-test-controllers-without-calling-views/146242 "2008-08-19T12:34:46Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![daniel304](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e5b9ba/32.png) [@daniel304](https://www.ruby-forum.com/u/daniel304)\
**Post date:** [August 19, 2008, 12:34pm UTC](https://www.ruby-forum.com/t/is-it-possible-to-test-controllers-without-calling-views/146242/1 "2008-08-19T12:34:46Z")

</div>

Let’s imagine, that we test a controller method - isolated peace of  
code with a well-defined responsibility: treat request and produce  
response (and may be also authorize user). We set up our mocks and  
stubs, i.e. doing minimal setup for running single method.

And what we have? Test fails because view-file called methods of your  
model, which you did not mocked or stubbed. So, we have to setup  
UNNESSESARY stub-methods/mock-expectations because of code, which has  
no meaning during the test. As a result, our nice simple test code  
grows up to a unreadable monster.

Does anyone have experience with solving this problem?

---

<div class="post-metadata">

**Author:** ![daniel304](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e5b9ba/32.png) [@daniel304](https://www.ruby-forum.com/u/daniel304)\
**Post date:** [August 19, 2008, 12:42pm UTC](https://www.ruby-forum.com/t/is-it-possible-to-test-controllers-without-calling-views/146242/2 "2008-08-19T12:42:25Z")

</div>

On 19 Aug 2008, at 11:33, Daniel V. wrote:

> grows up to a unreadable monster.  
> Could you stub the render method ? (don’t you want to know if there’s  
> a typo etc… in your view?)

Fred

---

<div class="post-metadata">

**Author:** ![daniel304](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e5b9ba/32.png) [@daniel304](https://www.ruby-forum.com/u/daniel304)\
**Post date:** [August 19, 2008, 12:50pm UTC](https://www.ruby-forum.com/t/is-it-possible-to-test-controllers-without-calling-views/146242/3 "2008-08-19T12:50:37Z")

</div>

> Could you stub the render method ?  
> Thank for idea, Fred, it could works, I’ll try

> (don’t you want to know if there’s a typo etc… in your view?)  
> Yes, I agree, it is important role of functional tests: they prevent  
> dumb mistakes. But I prefer to write a separate test for that, often  
> with fixtures.

---

<div class="post-metadata">

**Author:** ![daniel304](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/e5b9ba/32.png) [@daniel304](https://www.ruby-forum.com/u/daniel304)\
**Post date:** [August 20, 2008, 11:36am UTC](https://www.ruby-forum.com/t/is-it-possible-to-test-controllers-without-calling-views/146242/4 "2008-08-20T11:36:44Z")

</div>

Daniel V. wrote:

> Does anyone have experience with solving this problem?

You have way too many mocks. The “minimal setup” rule does not mean “set  
as few  
of your real objects up as possible”.

It means that the fewer mocks you must use, and the fewer objects you  
must setup  
to test something, the more clean, lean, and decoupled your code is.  
Expensive  
setup is a design smell, and mocks are _more_ expensive than production  
objects.  
All your objects should be ready to work in a minimal state without  
extra work  
to set them up.

You should only mock expensive things, such as hardware, random numbers,  
the  
system clock, etc.

Leave your mocks in this test, and (if you use Mocha) use Mocha’s  
any\_instance  
to whack the model methods you can’t bear to call. Then, in your next  
test, turn  
on the fixtures you need to truly test, and call everything without any  
mocks.

TDD is not “unit testing”, which is a Quality Control concept of  
mission-critical applications. TDD is about serendipitous cross-testing  
of many  
features out of each test case. Unit tests with overlapping units are  
bad; TDD  
with overlapping units is good.

–  
Phlip