Proposal for date/time setters

[Stephan]

Hello group,

internally in my project we have an extension of attribute setters in
use that allows us to use special setters for the value of datetime
and date fields. We are overwriting the setters for such fields to
allow for the following:

(\d+) (days?|weeks?|months?) (from now|ago), tomorrow, today,
yesterday

This allows steps like the following:
Given a post exists with created_at: "2 days ago"

Complementary to this, we have created time travel steps that allow
you to state something like
Given 2 days pass

If you think this is a valuable addition to pickle in general, I can
work on bringing those changes into pickle directly.

However, I first wanted to collect ideas on this...

Stephan

[Oriol Gual]

+1 for the time travel steps. I was actually thinking of writing them
so it would be great if you publish them.

[Ian White]

Hi Stephan,

This sounds great.

How hard would it be for the quote syntax swapped out in favour of no
quotes? e.g.

Given a post exists with created_at: 2 days ago

This would preserve parity with the way other pickle fields work at
present, and prevent the edge case of somebody doing:

Given a report exists with client_quote: "2 days ago"

Cheers,
Ian

> --
> You received this message because you are subscribed to the Google
> Groups "pickle" group.
> To post to this group, send email to pickle-...@googlegroups.com.
> To unsubscribe from this group, send email to pickle-cucumb...@googlegroups.com
> .
> For more options, visit this group at http://groups.google.com/group/pickle-cucumber?hl=en
> .
>

[tomtt]

> +1 for the time travel steps. I was actually thinking of writing them
> so it would be great if you publish them.

A far better and more generic solution is to modify pickle to use
cucumber transforms on it's arguments. That way the parser does not
have to be complicated with extra steps. We at Unboxed have been using
this technique successfully in several projects. Here is the code
snippet that does that - it lives in features/support/
pickle_extensions.rb:

http://gist.github.com/327131

Then all you need is a transform like this:
Transform /^(\d+) (second|minute|hour|day|week|fortnight|year)s?
(from[_ ]now|ago)$/ do |number, unit, time_arrow|
number.to_i.send(unit).send(time_arrow.tr(' ', '_'))
end

And then a step like this just works:
Given a match exists with start_date: "3 days from now"

Ian: the code gets a bit complex due to the alias_method_chain for
parse_field. It seems to me that a similar functionality could be
obtained using transforms which would both generalize and simplify
pickle. Any thoughts?

Tom.

-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Tom ten Thij
Unboxed Consulting, http://unboxedconsulting.com
T: +44 20 3137 2943 F: +44 20 7183 4251
-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~

[Ian White]

Hi Tom,

I think you're right: Make pickle's field args able to be transformed.

Thanks for reminding me about this transforms stuff - I need to get on
that... tomorrow.

Cheers,
Ian

[Ian White]

> Ian: the code gets a bit complex due to the alias_method_chain for
> parse_field. It seems to me that a similar functionality could be
> obtained using transforms which would both generalize and simplify
> pickle. Any thoughts?

Could you elaborate on this last point - are you suggesting using
transforms for part of pickle's parsing functionality? (the bit where
the parser becomes session (ie. current pickle refs) aware?

Cheers,
Ian

[Stephan]

Hi,

@Oriol
The time travel steps have nothing to with pickle actually. Here they
are:
http://gist.github.com/327914

Stephan

[Stephan]

Hi Tom,

thanks for your solution. I just implemented it and it works great!

However, there is one thing. It seems I am trading less "pollution" in
the step implementations for more "pollution" in step formulation.
After all, anything that matches the transformation can't be used for
anything else.

Stephan

> Unboxed Consulting,http://unboxedconsulting.com

[tomtt]

> However, there is one thing. It seems I am trading less "pollution" in
> the step implementations for more "pollution" in step formulation.
> After all, anything that matches the transformation can't be used for
> anything else.

This hasn't been an issue on any of the projects we have used this
for. Could you give an example where this would be an issue?

I see how it would be hard to ensure that there are no ambiguous
transform matches if you have a lot of transforms, but in practice we
have needed a few of them and this hasn't been an issue. The way you
would write things like "2 weeks ago" is already fairly distinct.

If we choose to get rid of some parser matches in favour of transforms
we of course will have to make sure that it can be done without
introducing (too much) spurious syntax and without causing ambiguous
matches.

Tom.

-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
Tom ten Thij
Unboxed Consulting, http://unboxedconsulting.com

[tomtt]

> The time travel steps [are here]:

This is such a bad idea it makes me shudder :). Stubbing in general
should be avoided in whole-stack integration tests, except in cases
where you rely on external services. Stubbing out the system time will
make your tests unreliable and may give strange results or cause
cucumber to pass when production is broken. Keep in mind that while
you may stub out system time, you have no control over your database's
time. Also when stubbing out time in integration tests, it may affect
things that you are not aware of in subtle unpredictable ways.

* Shudder *.

In fact the ability to specify times relative to now was the driving
force behind me writing the transform solution. Now I can just set up
my models to have dates relative to the current time and test the
system behaviour now. No time travel required.

I'll calm down now :).

[Stephan]

Hi Tom,

external services could be the one stubbing reason. I believe time may
be another. We use it, for example, to test billing runs that should
have been initiated only after a certain time passes. We make sure to
tear down any stubbing in between scenarios. The one aspect in which
the stubbing I mentioned could be improved is that a time travel
should not halt the progress of time (which it now does). I'd like to
make sure that time leaps, but continues after being stubbed.

Stephan

On Mar 10, 11:38 pm, tomtt <tomtent...@gmail.com> wrote:
> > The time travel steps [are here]:
>
> This is such a bad idea it makes me shudder :). Stubbing in general
> should be avoided in whole-stack integration tests, except in cases
> where you rely on external services. Stubbing out the system time will
> make your tests unreliable and may give strange results or cause
> cucumber to pass when production is broken. Keep in mind that while
> you may stub out system time, you have no control over your database's
> time. Also when stubbing out time in integration tests, it may affect
> things that you are not aware of in subtle unpredictable ways.
>
> * Shudder *.
>
> In fact the ability to specify times relative to now was the driving
> force behind me writing the transform solution. Now I can just set up
> my models to have dates relative to the current time and test the
> system behaviour now. No time travel required.
>
> I'll calm down now :).
>
> Tom.
>
> -~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~-~
> Tom ten Thij

> Unboxed Consulting,http://unboxedconsulting.com