On Thu, Jun 5, 2008 at 5:46 AM, Doug Livesey <[EMAIL PROTECTED]> wrote:
> I have two questions with it. The first is, would it be possible to set
> it up to test the case when each_row operates on an empty Array?
If there were no rows, each_row wouldn't yield at all, so you should
just be able to
On Wed, Jun 4, 2008 at 9:06 AM, Matthew Lins <[EMAIL PROTECTED]> wrote:
> I realize I could do this differently and just do a should_receive on the
> OrderItem, looking for '+=' or something, but that doesn't feel right.
I know this isn't what you're looking for, but note that whether you do:
it
I do that sort of thing pretty often.
I would just point out that you should avoid calling that mocking, since
there are no expectations in place and therefore no verification of the
specific way the code being specified interacts with the MigrationGraph.
According to the definitions in
http://mar
On Wed, May 14, 2008 at 2:17 AM, EAW <[EMAIL PROTECTED]> wrote:
> It seems that this method is clashing with one of the methods in rspec. Is
> there a workaround for this situation? It's a pain to have to rename my
> method everytime I want to see a proper failure message from rspec.
Not to be
Even when working test/spec-first, when I'm pairing with someone who isn't
experienced working that way, I find myself constantly saying "I'm pretty
sure we don't need that yet." (I've just written the spec my pair is trying
to get passing, so I know how little code we need.) If it happens then,
I believe calls to super are sufficiently internal to the Ruby interpreter
that a mocking framework can't intercept them without doing separate
implementations for separate Ruby interpreters (and likely even separate
versions). I could be wrong, but even so I'd recommend a different
approach.
If
Ben,
You're trying to test more than one thing in one spec. The gutter
that's steered you into here is that you're looking for side-effects
of a method you've mocked. Your spec says to make sure the template
calls "body_class" and to have the call return a string, but that's
not how the body_clas
Will,
I wanted to do something similar. To avoid losing all the tasks and
other goodness Spec::Rails gives you for free, I just created a
separate top-level directory.
/spec
/models
/controllers
...
/unit
/models
...
(It bugs me not having it all contained in one directory, but it's
co
Your implementation looks so much like a ModelFactory my team
implemented last week that it's scary. Anyway ...
Is it a typo that you show the "create_..." methods being def'd as
module methods (i.e., "def self.create...") while the
"valid_..._attribute" methods are instance methods? That would
