On Thu, Jan 7, 2010 at 5:09 AM, Matt Wynne wrote:
>
> On 7 Jan 2010, at 07:22, Wincent Colaiuta wrote:
>
>> El 07/01/2010, a las 03:53, Phillip Koebbe escribió:
>>
>>> Wincent Colaiuta wrote:
Well, there is more than one way to skin a cat, but the thing I like
about my proposed solu
To all involved,
Great discussion! Thank you so much for taking the time out of your
busy lives to contribute. Please believe me when I say that I
appreciate it *very* much!
Here is the latest version of my code:
http://gist.github.com/269544
I like the idea of shared examples (trying to use th
2010/1/7 Phillip Koebbe
>
>
> Wincent Colaiuta wrote:
>
>>
>> Well, there is more than one way to skin a cat, but the thing I like about
>> my proposed solution is that:
>>
>> - the specification of the behavior appears in the "describe" block that
>> corresponds to the controller where the behav
On 7 Jan 2010, at 07:22, Wincent Colaiuta wrote:
El 07/01/2010, a las 03:53, Phillip Koebbe escribió:
Wincent Colaiuta wrote:
Well, there is more than one way to skin a cat, but the thing I
like about my proposed solution is that:
- the specification of the behavior appears in the "desc
El 07/01/2010, a las 03:53, Phillip Koebbe escribió:
Wincent Colaiuta wrote:
Well, there is more than one way to skin a cat, but the thing I
like about my proposed solution is that:
- the specification of the behavior appears in the "describe" block
that corresponds to the controller whe
On Wed, Jan 6, 2010 at 8:53 PM, Phillip Koebbe wrote:
>
>
> Wincent Colaiuta wrote:
>
>>
>> Well, there is more than one way to skin a cat, but the thing I like about
>> my proposed solution is that:
>>
>> - the specification of the behavior appears in the "describe" block that
>> corresponds to t
Wincent Colaiuta wrote:
Well, there is more than one way to skin a cat, but the thing I like
about my proposed solution is that:
- the specification of the behavior appears in the "describe" block
that corresponds to the controller where the behavior is implemented
- but given that the i
El 06/01/2010, a las 16:17, Phillip Koebbe escribió:
Wincent Colaiuta wrote:
I test inherited stuff with shared behaviors. It might be something
you could use here.
Basically, I have a bunch of behavior in my ApplicationController,
for example, and in my spec/controllers/
application_co
Wincent Colaiuta wrote:
I test inherited stuff with shared behaviors. It might be something
you could use here.
Basically, I have a bunch of behavior in my ApplicationController, for
example, and in my spec/controllers/application_controller_spec.rb
file I have a bunch of blocks like this
On Tue, Jan 5, 2010 at 6:44 PM, Wincent Colaiuta wrote:
> El 05/01/2010, a las 21:52, Phillip Koebbe escribió:
>
>
> Pat Maddox wrote:
>>
>>> The spec has Admin::BaseController as the described type. So of course
>>> it's going to test against that. If you want to test a different class, you
>
El 05/01/2010, a las 21:52, Phillip Koebbe escribió:
Pat Maddox wrote:
The spec has Admin::BaseController as the described type. So of
course it's going to test against that. If you want to test a
different class, you need to describe that instead!
Hi Pat,
Right. But, I'm not really wan
On Tue, Jan 5, 2010 at 2:53 PM, Phillip Koebbe wrote:
> Subclass it in your spec with
>>
>> class TestController < Admin::BaseController
>> def index
>> end
>> end
>>
>> ...then use the TestController in your tests for Admin::BaseController.
>>
>> That might mean you'll need to add special rou
Subclass it in your spec with
class TestController < Admin::BaseController
def index
end
end
...then use the TestController in your tests for Admin::BaseController.
That might mean you'll need to add special routing for TestController
which is annoying but can be done.
Thanks, Matt. Be
Pat Maddox wrote:
The spec has Admin::BaseController as the described type. So of course it's
going to test against that. If you want to test a different class, you need to
describe that instead!
Hi Pat,
Right. But, I'm not really wanting to test a different class. My
intention is to pu
On Tue, Jan 5, 2010 at 1:46 PM, Matt Wynne wrote:
> Subclass it in your spec with
>
> class TestController < Admin::BaseController
> def index
> end
> end
>
> ...then use the TestController in your tests for Admin::BaseController.
>
> That might mean you'll need to add special routing for Tes
Subclass it in your spec with
class TestController < Admin::BaseController
def index
end
end
...then use the TestController in your tests for Admin::BaseController.
That might mean you'll need to add special routing for TestController
which is annoying but can be done.
On 5 Jan 2010,
The spec has Admin::BaseController as the described type. So of course it's
going to test against that. If you want to test a different class, you need to
describe that instead!
On Jan 5, 2010, at 9:36 AM, Phillip Koebbe wrote:
> I'm trying to implement a base controller that other controller
I'm trying to implement a base controller that other controllers descend
from, and am having a bit of difficulty in testing the sole "feature" of
the base controller.
http://gist.github.com/269544
In the "not redirecting when user is an admin" context, I keep getting
an error that "no action
18 matches
Mail list logo
