Woohoo! I was aware of the block construct, but didn't know it worked
with stub! as well (with should_receive, I had to use at_least... and
it broke the system, making it unusable).
Thanks!
___
rspec-users mailing list
rspec-users@rubyforge.org
http://ru
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
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
On Wed, Dec 30, 2009 at 10:30 AM, John j. Cuckler wrote:
> Hi, I just wrote some specs for a rails plugin, I'm using some
> fixtures and rake:spec:plugins works fine as long as there is only
> this plugin loaded in the application, but if I add another one it
> doesn't load fixtures. Apart from t
On 5 Jan 2010, at 12:17, Matt Patterson wrote:
On 9 Nov 2009, at 22:03, Matt Wynne wrote:
On 6 Nov 2009, at 12:49, David Chelimsky wrote:
In the long run, what I'd like is the following:
* Cucumber features that ship with RSpec become the authoritative
end-user documentation. This is so
We seem to be hitting some undesirable behavior with should_not in
combination with matchers that accept collections. Let me use the "include"
matcher for example (a co-worker reported similar problems using "be_any" so
I don't believe this is limited to "include"). The RDoc states:
Passes if a
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
On Wed, Jan 6, 2010 at 7:15 PM, Ben Fyvie wrote:
> We seem to be hitting some undesirable behavior with should_not in
> combination with matchers that accept collections. Let me use the “include”
> matcher for example (a co-worker reported similar problems using “be_any” so
> I don’t believe this
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
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
10 matches
Mail list logo
