[rspec-users] what RSpec approach could I use for this.

David Chelimsky dchelimsky at gmail.com
Sun Mar 4 08:55:39 UTC 2012

On Sat, Mar 3, 2012 at 4:29 PM, Justin Ko <jko170 at gmail.com> wrote:
> On Mar 3, 2012, at 2:55 PM, Greg C. wrote:
>> Background:  So I have roughly:
>> class A
>>   def calculate_input_datetimes
>>      # do stuff to calculate datetimes - then for each one identified
>>      process_datetimes(my_datetime_start, my_datetime_end)
>>   end
>>   def process_datetimes(input_datetime_start, input_datetime_end)
>>      # do stuff
>>   end
>> end
>> So:
>> * I want to test that calculate_input_datetimes algorithms are working
>> and calculating the correct datetimes to pass to process_datetimes
>> * I know I can STUB out process_datetimes so that it's code won't be
>> involved in the test
>> QUESTION:  How can I setup the rspec test however so I can specifically
>> test that the correct datestimes were attempted to be passed over to
>> process_datetimes,  So for a given spec test that process_datetimes was
>> called three (3) times say with the following parameters passed:
>> * 2012-03-03T00:00:00+00:00, 2012-03-09T23:59:59+00:00
>> * 2012-03-10T00:00:00+00:00, 2012-03-16T23:59:59+00:00
>> * 2012-03-17T00:00:00+00:00, 2012-03-23T23:59:59+00:00
> Setup 3 individual expectations:
> a_instance.should_receive(:process_datetimes).with(input_datetime_start_1, datetime_end_1).once.ordered
> a_instance.should_receive(:process_datetimes).with(input_datetime_start_2, datetime_end_2).once.ordered
> Your 2 methods should be tested in isolation (unless #process_datetimes is private). So for #calculate_input_datetimes, just ensure that #process_datetimes is called with the correct arguments. The, test #processs_datetimes in isolation.

Stubbing internals of the subject of the example can hide subtle bugs.
I'd just specify this in terms of initial state and output of
calculate_input_datetimes. I'll be more specific if you will (i.e.
what does this object/method actually do)?

More information about the rspec-users mailing list