Forum: RSpec [cucumber] Cucumber and Chronic

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
3464536ce6396bacc132ad18d2c46489?d=identicon&s=25 Tim Walker (timw)
on 2009-03-01 17:58
(Received via mailing list)
This may have been discussed before but just wanted to pass along a
killer one-two punch that we stumbled upon as an excellent and natural
extension to our domain language around the expression and testing of
complex time based constructs.

Please consider:

Cucumber allows you to specify behavior in natural language.

Chronic is a natural language date/time parser written in pure Ruby.
(http://chronic.rubyforge.org/)

Example of a cucumber test:

Scenario: Test control operations
Given that I have have a control operation named “set clock date time”
to “Monday Jan 1, 2009 10:00”
When the control named “set clock date time” runs
Then the clock should be “10:00”

Now, this works fine, if you’re only testing that you can set the
clock to "Monday Jan 1, 2009 10:00". It gets more complex quickly when
you try to do much more than this. Adding chronic to the mix allows us
to define and use more complex time concepts in plain language. This
allows for the parsing of sentence fragments such as “next month” and
“next Tuesday” and combine them in to complex structures such as “next
Tuesday at 9:00” in a way that our tests continue to run as time
marches on.

For example:
>> sentence = "next tuesday at 3:00 pm"
=> "next tuesday at 3:00 pm"
>> time = Chronic.parse(sentence)
=> Tue Mar 03 15:00:00 -0700 2009

Now, the scenario can use this easily express clearly “when” the
control operation runs in more complex and useful expressions, for
example:

Scenario: Test control operations
Given that I have have a control operation named “set clock date time”
to "next tuesday at 3:00 pm"
When the control named “set clock date time” runs
Then the clock should be “next tuesday at 3:00 pm"

Scenario: Test spy sweeping schedules
Given that I have have a control operation named “clean spies”  that
is scheduled to run “next Monday at 8:00 AM"
And the customer has excluded “weekdays” from allowing the control
operation “clean spies” to run
When the control named “set clock time” runs
Then it should log a message and quit
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2009-03-01 20:18
(Received via mailing list)
On Sun, Mar 1, 2009 at 8:50 AM, Tim Walker <walketim@gmail.com> wrote:
> For example:
>>> sentence = "next tuesday at 3:00 pm"
> => "next tuesday at 3:00 pm"
>>> time = Chronic.parse(sentence)
> => Tue Mar 03 15:00:00 -0700 2009

Just be careful when when basing durations from "now" that daylight
savings time doesn't affect anything.

///ark
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2009-03-02 00:32
(Received via mailing list)
On Sun, Mar 1, 2009 at 11:07 AM, Mark Wilden <mark@mwilden.com> wrote:
>
> Just be careful when when basing durations from "now" that daylight
> savings time doesn't affect anything.

Along the same lines, don't write tests that assume 1.month.ago was <
29 days ago, or specs could start failing in March (as just happened
with us). :)

///ark
994e42bda994be2cd1d791f18ee6d561?d=identicon&s=25 Stephen Eley (Guest)
on 2009-03-02 06:17
(Received via mailing list)
On Sun, Mar 1, 2009 at 6:30 PM, Mark Wilden <mark@mwilden.com> wrote:
> On Sun, Mar 1, 2009 at 11:07 AM, Mark Wilden <mark@mwilden.com> wrote:
>>
>> Just be careful when when basing durations from "now" that daylight
>> savings time doesn't affect anything.
>
> Along the same lines, don't write tests that assume 1.month.ago was <
> 29 days ago, or specs could start failing in March (as just happened
> with us). :)

You wouldn't happen to be on the Microsoft Zune development team,
would you?  >8->

For date testing, I've just discovered and successfully used Notahat's
"time_travel" plugin:
http://github.com/notahat/time_travel/

It's essentially a scoped override for Time.now, so that any code you
pass it executes as if the current time is frozen at whatever you tell
it.  This makes repeatable testing much, much simpler.  This is the
same guy who developed Machinist (my preferred fixture/factory tool)
and not_a_mock, which I used for a little while before I abandoned
mocking.  >8->  So...yeah.  He does good stuff.


--
Have Fun,
   Steve Eley (sfeley@gmail.com)
   ESCAPE POD - The Science Fiction Podcast Magazine
   http://www.escapepod.org
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2009-03-02 18:33
(Received via mailing list)
On Sun, Mar 1, 2009 at 9:07 PM, Stephen Eley <sfeley@gmail.com> wrote:
>
> For date testing, I've just discovered and successfully used Notahat's
> "time_travel" plugin:
> http://github.com/notahat/time_travel/

We have just been stubbing Time.now, but I'll think about time_travel.
One advantage would be not having to "manually" reset RSpec mocks
after each Cucumber scenario is run in After.

///ark
3464536ce6396bacc132ad18d2c46489?d=identicon&s=25 Tim Walker (timw)
on 2009-03-03 03:04
(Received via mailing list)
Absolutely. I'd respectfully suggest that this is more a requirement
of the way the step definition or test fixture that implements the
feature needs to behave than the intent of describing time based logic
in a natural language such that product owners, ba's etc. can write
them (i.e. Cucumber, FitNesse, etc). That Chronic takes into
consideration the things you mention (time zone, DST, Leap Years,
etc), is simply an imperative of it. Anyway, I think it fits
hand-in-glve with Cucumber and BDD in general. Just for the record, I
have no vested interest in Chronic and really don't know who even
authored it, but I can say it's looking pretty awesome in our own
Cucumber tests.

Thanks,

Tim
48641c4be1fbe167929fb16c9fd94990?d=identicon&s=25 Mark Wilden (Guest)
on 2009-03-07 20:16
(Received via mailing list)
On Sun, Mar 1, 2009 at 11:07 AM, Mark Wilden <mark@mwilden.com> wrote:
>
> Just be careful when when basing durations from "now" that daylight
> savings time doesn't affect anything.

Like it did today, when two specs that used 'Time.now.advance(:hours
=> 24).utc' started failing.

///ark
This topic is locked and can not be replied to.