[rspec-users] Weird failing spec

David Chelimsky dchelimsky at gmail.com
Sat Oct 27 10:36:59 EDT 2007

On 10/27/07, Ashley Moran <work at ashleymoran.me.uk> wrote:
> On Oct 27, 2007, at 9:45 am, Tarsoly András wrote:
> > This raises up a question in me about mocking or using real-life
> > models, because in some of my specs the setups getting extremely
> > bulky. But this is for another topic :)

Bulky setup is a design smell. That doesn't mean it never happens, but
when it does you should ask yourself what you can do to improve the
design. If you're not familiar with the Law of Demeter, search around
for it and give it some thought.

> Well while you have everyone's attention :)
> Often you can factor out the setup code - if you search through the
> archives of this list there's plenty of examples.  But don't worry
> about having long setups - I've written some setups that aren't much
> shorter than the specs that follow.  Write whatever setup you need to
> enable you to write solid specs, then worry after about making it
> look nice.

In spite of what I said earlier, this is true. For specs, coming from
TDD, "the way" is to get from red to green and then refactor. The
refactoring step should be considered every time you get to green.
Where is duplication? How can I improve the design to eliminate it?
You won't always actually do anything, but the thought process is very
important. It's like a 24/7 design review.

> I would say you should ALWAYS mock your models in your controllers
> specs.  Otherwise you will further complicate your setups, make your
> specs run unacceptably slow, and you risk coupling your controllers
> and models too tightly.  Many people in the BDD community (and at a
> guess I am assuming David is among them) would frown on using
> database access in your *model* code, because persistence is a
> separate issue to business logic.

If I were writing the framework, this would be true. But Rails
provides efficiencies in exchange for blending these concepts in to
one. It's a trade off, but I've come to appreciate the efficiencies
enough where I live with it.

> What you want is a set of specs for each of model (ideally, database
> persistence and business logic separately

Do you mean like this?


Or do you just mean separating the concerns within a single spec document?

> ), controller, and view, and
> then an integration test, such as an RSpec story, that tests the full
> stack.  Without this integration step, you will miss errors when you
> change the interface of a model.  What you do not want is the Rails
> way of testing, where each layer of testing re-tests everything below
> it.  (I recently saw a blog post where someone asked for comments on
> how people test views in isolation - it never occurred to me that
> some Rails developers still see that as an issue!)
> Having thought about it, you could argue Rail has no *unit* testing
> support built in at all.

Absolutely agree. You have to go some distance to do any real unit
testing in Rails. But, on the flip side, you get so much for free that
you get from other more highly-decoupled framework that it might be
worth the trade-off. There's a balance in there somewhere ... let me
know when you find it :)


More information about the rspec-users mailing list