[rspec-users] Weird failing spec
work at ashleymoran.me.uk
Sat Oct 27 18:41:06 EDT 2007
On Oct 27, 2007, at 3:36 pm, David Chelimsky wrote:
> 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.
I don't think I have any LoD violations in my long setups. It's just
the sheer number of things that some pages need to load. It's
actually a while since I looked over the code I am referring to. It
may actually just be view specs I am thinking of, where bulky setups
are just a sign of the number of different things being displayed.
But either way, I'll be vigilant when I return to them.
> 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 just watched this today: <http://www.infoq.com/presentations/
Nothing revolutionary if you've been doing BDD in Ruby a while, but
one of the things he drives home is the idea that in Ruby (and
dynamic languages in general), you must have the shortest possible
cycles, and must always work to make sure quality of the code is
maintained as high as you can manage.
It's puzzling looking at developers who don't do BDD, who think that
refactoring is something you do when adding a new feature would cause
the collapse of half the application. I don't know how they live
with (a) the stress of leaving a mess behind them and (b) the
impending nervous breakdown when they actually have to fix it (with
nothing to tell them it still works!) I dread to look at some of the
code that is developed with none of the principles you describe
above. Hell, mine is bad enough sometimes and I make the effort.
>> 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.
You've become unusually forgiving lately :)
>> 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
I'd never thought about splitting them into directories like that.
Currently I just make sure that associations have a separate spec
block to the others, something like
describe MyModel do
describe MyModel, "associations" do
There's probably not so much to do with ActiveRecord, because your
models HAVE to map directly to tables. But I still test separately
the persistence of any custom methods that build object graphs.
> 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 :)
I still believe that Ruby is powerful enough that we can build highly-
decoupled frameworks that collapse down to the simple cases by
default. Something that has Rails' beauty on the inside as well as
the outside. I'll let you know when I find *that*!
blog @ http://aviewfromafar.net/
linked-in @ http://www.linkedin.com/in/ashleymoran
currently @ home
More information about the rspec-users