David Chelimsky-2 wrote:
>
> 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:
>>
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 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
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"
.
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
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 behaviours
what I have now is a generic file which contains al
