On 8/4/07, David Green <[EMAIL PROTECTED]> wrote:
>
> I have a lot of controllers with virtually identical functionality for most
> actions. I've been using shared behaviours to DRY things up a bit, but I
> still have to create separate behaviours for each context before I can use
> the shared beha
that's a great point, but there are some things about shared behaviours I
don't like. for example, I have 14 different contexts I'm testing (and more
to come) in 8 controllers.
I can do this:
describe MyController do
it_should_behave_like "context 1"
it_should_behave_like "context 2"
.
I agree with David, I think this is too much magic.
You'll often have more duplication in specs than you will in
production code. That's not a bad thing though, because specs need to
be explicit about the behavior being performed. Duplication doesn't
lead to the same mistakes that it does in pro
On 8/5/07, David Green <[EMAIL PROTECTED]> wrote:
>
> that's a great point, but there are some things about shared behaviours I
> don't like. for example, I have 14 different contexts I'm testing (and more
> to come) in 8 controllers.
>
> I can do this:
>
> describe MyController do
> it_should_be
I have a mock of an instance of a class which descends from Array:
class ArrayDescendent < Array; end
#... in the specs...
@descendent = mock ArrayDescendent
How would I stub out ArrayDescendent#each, which is inherited from
Array, to return multiple values successively? I could use
and_yi
Is there some reason that pending() *MUST* take an argument?
Scott
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/listinfo/rspec-users
On 8/5/07, Scott Taylor <[EMAIL PROTECTED]> wrote:
>
> I have a mock of an instance of a class which descends from Array:
>
> class ArrayDescendent < Array; end
>
> #... in the specs...
> @descendent = mock ArrayDescendent
>
> How would I stub out ArrayDescendent#each, which is inherited from
> Arr
I believe for rails projects you can put rspec's code repos into
vendor/plugins, and autotest will automatically use the rspec binary
in that directory, and not the gem installed.
Is there an easy way to do this for non-rails projects? There are a
few advancements on trunk which I would li
