On 15 Jul 2010, at 14:55, Chuck Remes wrote:
>
> On Jul 14, 2010, at 4:20 PM, Matt Wynne wrote:
>
>>
>> You can do this, by using a test spy to remember the value of foo passed
>> into the stubbed constructor and then later comparing it:
>>
>> let(:foo) { Foo.new }
>>
>> it "should allocate
On 16 Jul 2010, at 10:29, Matt Wynne wrote:
>> For those following along at home, this exact technique did not work. The
>> +actual_foo+ variable was holding some mock value instead of the real self
>> value.
> Sorry. Do we think this is a bug in rspec? I'd have expected the block to
> return th
On Jul 16, 2010, at 4:45 AM, Tom Stuart wrote:
> On 16 Jul 2010, at 10:29, Matt Wynne wrote:
>>> For those following along at home, this exact technique did not work. The
>>> +actual_foo+ variable was holding some mock value instead of the real self
>>> value.
>> Sorry. Do we think this is a bug
On 16 Jul 2010, at 10:45, Tom Stuart wrote:
> On 16 Jul 2010, at 10:29, Matt Wynne wrote:
>>> For those following along at home, this exact technique did not work. The
>>> +actual_foo+ variable was holding some mock value instead of the real self
>>> value.
>> Sorry. Do we think this is a bug i
On Jul 15, 2010, at 12:18 PM, Greg Ditrick wrote:
> All,
>
> I have a method in a shared Module that shuffles data and then output other
> data. The method is somewhat large (maybe 50 lines) and sometimes calls
> other sub methods to help to complete the output which must meet a specific
> c
On Jul 15, 2010, at 6:24 PM, Matt Kolenda wrote:
> Hello
>
> I'm having some trouble getting rspec to recognize a route.
>
> # This works
> describe "routes" do
> it "should have a route" do
> { :get => "/accounts/3/jobs/3/
> applications/1/edit" }.should route_to(:controller =>
Hey all,
For anyone interested in shared example groups, please read and feel free to
comment on http://github.com/rspec/rspec-core/issues/#issue/71.
Cheers,
David
___
rspec-users mailing list
rspec-users@rubyforge.org
http://rubyforge.org/mailman/list
David Chelimsky wrote:
> On Jul 15, 2010, at 12:18 PM, Greg Ditrick wrote:
>
>
> This sounds like a long, procedural method. Can it be broken down any further
> (i.e. delegating more of its work to other methods)?
Yes, it is. The sub methods are the broken down part and not overridden s
On Jul 16, 2010, at 11:38 AM, Greg Ditrick wrote:
> David Chelimsky wrote:
>> On Jul 15, 2010, at 12:18 PM, Greg Ditrick wrote:
>>
>>
>> This sounds like a long, procedural method. Can it be broken down any
>> further (i.e. delegating more of its work to other methods)?
>
> Yes, it is.
