[rspec-users] Prepare for newbie-ness

aslak hellesoy aslak.hellesoy at gmail.com
Wed Sep 17 18:58:20 EDT 2008

On Tue, Sep 16, 2008 at 7:00 PM, Martin Streicher
<martin.streicher at gmail.com> wrote:
> A few questions from someone new to rspec.
> 1/ I have several complex yet largely independent models using rspec to test
> internals and computation methods. I am about to tackle models that have
> several ties to each other and to the "primitive", independent models.
> One model has stuff like this:
> class Message ...
>  belongs_to  :contact
>  belongs_to  :topic
>  has_one     :header
>  has_many    :parts
>  has_many    :attachments
> My question:
> What is the best practice for testing models with these interdependencies?

Can we all please stop talking about "best" practices? It always
depends. If people talk about best practices then others will be more
inclined to apply them without thinking.


> What would you recommend for Message? What about Topic, which has_many
> Messages? Do I mock these? Use canonical data in the code rather than use a
> fixture?

"Testing a model" or "testing a relationship" doesn't mean much (it
can mean anything). I recommend you focus your testing efforts on the
desired *behaviour* of your system, not its implementation. This is a
very central tenet of BDD.

If your Message class doesn't have any behaviour (code in addition to
the relationships) there isn't really much about it to test. You
should assume ActiveRecord works.

I suppose those relationships are there for a reason. Some other code
uses these relationships. What is that code? Start by testing that
code. This code is probably on the "outside" of your model, i.e. it
depends on your model. Typically a controller and/or a view - probably

Nowadays I usually recommend people start by writing a test for the
system as seen from the outside. This is called "outside in" and is
what you'd use Cucumber or the story runner for. Or if you don't use
it, at least write some kind of end to end test. Then, when you
discover edge cases, drop down to a lower level (specs that talk to
the model).

I have a feeling I might have confused you more than helped you. Maybe
you can explain a little more about what the system's behaviour? It
would help set the context so we can recommend a good practice ;-)


> 2/ Related to (1), I have not found much documentation about such
> techniques. Pointers? Examples? Mentorship? Blogs?
> 3/ Has any documented how to run the debugger via rspec to help track down
> errors?
> Martin
> _______________________________________________
> rspec-users mailing list
> rspec-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/rspec-users

More information about the rspec-users mailing list