Changing time while system testing

[inanc]

We'r running a system test that should test all of the components which are distributed. But, we need to change the time for the testing to work as intended.

What do you suggest? Should we change the system time of the machines which components are running or should we tell components to change their times? etc.?

[Ted Young-5]

This is pretty straightforward: any component or piece of code that needs
the current date and/or time should call a method on an object (either
injected or implemented as a singleton). That way during testing, you can
substitute the "real" time with a fake that returns whatever date or time
you want it to. For example:

...
public void doSomething(Clock clock) { // "inject" the clock
  ...
  Date now = clock.now();
  ...
}

or:

public void doSomething() {
  ...
  Date now = Clock.instance().now(); // Clock is a singleton
  ...
}

Changing the time of the underlying system itself is not a good idea -- I
know I wouldn't want tests that I run to be changing the time on my machine,
my appointment calendar would go crazy!

;ted


On Fri, Oct 9, 2009 at 12:44 AM, Inanc Gumus <inanc.gumus@...> wrote:

>
>
> We'r running a system test that should test all of the components which are
> distributed. But, we need to change the time for the testing to work as
> intended.
>
> What do you suggest? Should we change the system time of the machines which
> components are running or should we tell components to change their times?
> etc.?
>
>  
>

[Non-text portions of this message have been removed]

[Cenk Çivici]

Agree with Ted. This is referred to as Virtual Clock pattern.
On Fri, Oct 9, 2009 at 7:05 PM, Ted Young <tedyoung@...> wrote:

>
>
> This is pretty straightforward: any component or piece of code that needs
> the current date and/or time should call a method on an object (either
> injected or implemented as a singleton). That way during testing, you can
> substitute the "real" time with a fake that returns whatever date or time
> you want it to. For example:
>
> ...
> public void doSomething(Clock clock) { // "inject" the clock
> ...
> Date now = clock.now();
> ...
> }
>
> or:
>
> public void doSomething() {
> ...
> Date now = Clock.instance().now(); // Clock is a singleton
> ...
> }
>
> Changing the time of the underlying system itself is not a good idea -- I
> know I wouldn't want tests that I run to be changing the time on my
> machine,
> my appointment calendar would go crazy!
>
> ;ted
>
>
> On Fri, Oct 9, 2009 at 12:44 AM, Inanc Gumus <inanc.gumus@...<inanc.gumus%40gmail.com>>
> wrote:
>
> >
> >
> > We'r running a system test that should test all of the components which
> are
> > distributed. But, we need to change the time for the testing to work as
> > intended.
> >
> > What do you suggest? Should we change the system time of the machines
> which
> > components are running or should we tell components to change their
> times?
> > etc.?
> >
> >
> >
>
> [Non-text portions of this message have been removed]
>
>  
>

[Non-text portions of this message have been removed]

[Chirag-7]

A link to Virtual Clock pattern

http://c2.com/cgi/wiki?VirtualClock

Chirag.

--- In testdrivendevelopment@..., Cenk Çivici <cenk.civici@...> wrote:

>
> Agree with Ted. This is referred to as Virtual Clock pattern.
> On Fri, Oct 9, 2009 at 7:05 PM, Ted Young <tedyoung@...> wrote:
>
> >
> >
> > This is pretty straightforward: any component or piece of code that needs
> > the current date and/or time should call a method on an object (either
> > injected or implemented as a singleton). That way during testing, you can
> > substitute the "real" time with a fake that returns whatever date or time
> > you want it to. For example:
> >
> > ...
> > public void doSomething(Clock clock) { // "inject" the clock
> > ...
> > Date now = clock.now();
> > ...
> > }
> >
> > or:
> >
> > public void doSomething() {
> > ...
> > Date now = Clock.instance().now(); // Clock is a singleton
> > ...
> > }
> >
> > Changing the time of the underlying system itself is not a good idea -- I
> > know I wouldn't want tests that I run to be changing the time on my
> > machine,
> > my appointment calendar would go crazy!
> >
> > ;ted
> >
> >
> > On Fri, Oct 9, 2009 at 12:44 AM, Inanc Gumus <inanc.gumus@...<inanc.gumus%40gmail.com>>
> > wrote:
> >
> > >
> > >
> > > We'r running a system test that should test all of the components which
> > are
> > > distributed. But, we need to change the time for the testing to work as
> > > intended.
> > >
> > > What do you suggest? Should we change the system time of the machines
> > which
> > > components are running or should we tell components to change their
> > times?
> > > etc.?
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >  
> >
>
>
> [Non-text portions of this message have been removed]
>

[James Martin-7]

The venerable Virtual Clock pattern, Circa ~2002(?).

http://c2.com/cgi/wiki?VirtualClock


On Sat, Oct 10, 2009 at 6:56 AM, Cenk Çivici <cenk.civici@...> wrote:

> Agree with Ted. This is referred to as Virtual Clock pattern.
> On Fri, Oct 9, 2009 at 7:05 PM, Ted Young <tedyoung@...> wrote:
>
> >
> >
> > This is pretty straightforward: any component or piece of code that needs
> > the current date and/or time should call a method on an object (either
> > injected or implemented as a singleton). That way during testing, you can
> > substitute the "real" time with a fake that returns whatever date or time
> > you want it to. For example:
> >
> > ...
> > public void doSomething(Clock clock) { // "inject" the clock
> > ...
> > Date now = clock.now();
> > ...
> > }
> >
> > or:
> >
> > public void doSomething() {
> > ...
> > Date now = Clock.instance().now(); // Clock is a singleton
> > ...
> > }
> >
> > Changing the time of the underlying system itself is not a good idea -- I
> > know I wouldn't want tests that I run to be changing the time on my
> > machine,
> > my appointment calendar would go crazy!
> >
> > ;ted
> >
> >
> > On Fri, Oct 9, 2009 at 12:44 AM, Inanc Gumus <inanc.gumus@...
> <inanc.gumus%40gmail.com>>
> > wrote:
> >
> > >
> > >
> > > We'r running a system test that should test all of the components which
> > are
> > > distributed. But, we need to change the time for the testing to work as
> > > intended.
> > >
> > > What do you suggest? Should we change the system time of the machines
> > which
> > > components are running or should we tell components to change their
> > times?
> > > etc.?
> > >
> > >
> > >
> >
> > [Non-text portions of this message have been removed]
> >
> >
> >
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]

[Steven Smith-23]

This is one of those "insidious dependencies" that we don't always realize
is a dependency until it starts making our lives difficult during testing.
Others have already given the solution, but here's  post I did last year
that includes others you might wish to consider (read the comments as well):

http://stevesmithblog.com/blog/insidious-dependencies/

HTH,
Steve



On Fri, Oct 9, 2009 at 3:44 AM, Inanc Gumus <inanc.gumus@...> wrote:

>
>
> We'r running a system test that should test all of the components which are
> distributed. But, we need to change the time for the testing to work as
> intended.
>
> What do you suggest? Should we change the system time of the machines which
> components are running or should we tell components to change their times?
> etc.?
>
>
>

--
Steve Smith
http://SteveSmithBlog.com/
http://twitter.com/ardalis


[Non-text portions of this message have been removed]

[Rob Park-3]

Like the inclusion of new in the list.

//rob

Sent from my iPhone

On Oct 11, 2009, at 11:13 AM, Steven Smith <ssmith.lists@...>  
wrote:

> This is one of those "insidious dependencies" that we don't always  
> realize
> is a dependency until it starts making our lives difficult during  
> testing.
> Others have already given the solution, but here's post I did last  
> year
> that includes others you might wish to consider (read the comments  
> as well):
>
> http://stevesmithblog.com/blog/insidious-dependencies/
>
> HTH,
> Steve
>
> On Fri, Oct 9, 2009 at 3:44 AM, Inanc Gumus <inanc.gumus@...>  
> wrote:
>
> >
> >
> > We'r running a system test that should test all of the components  
> which are
> > distributed. But, we need to change the time for the testing to  
> work as
> > intended.
> >
> > What do you suggest? Should we change the system time of the  
> machines which
> > components are running or should we tell components to change  
> their times?
> > etc.?
> >
> >
> >
>
> --
> Steve Smith
> http://SteveSmithBlog.com/
> http://twitter.com/ardalis
>
> [Non-text portions of this message have been removed]
>
>

[Non-text portions of this message have been removed]

[Nat Pryce]

The original poster asked about *system* testing. In that case you
can't pass a fake clock to the system's objects because the tests are
exercising the system from outside and have no control over how the
processes that make up the system create their objects.

When system testing, I use a combination of the following approaches:

1) design the system so that most processes do not need to access the
system clock. E.g. by passing the time for which they are calculating
time-dependent values in the requests that they process. That might
involve adding a gateway between clients and the rest of the system to
assign a transaction time to each incoming request.

2) in the set-up of each test, generate test data that is relative to
the current time rather than containing fixed dates and times.

3) extract all scheduling functionality into a remote service that is
used by the other processes of the system. Treat that service as an
external dependency. Test it heavily but use a fake implementation in
the system tests so that the tests can check requested schedules and
invoke scheduled activities faster than real-time.

4) exercise time-based calculations with fine-grained unit tests or
acceptance tests that drivethe domain model directly. Make much
coarser assertions about their results in system tests.

Hope that helps.

--Nat

On Friday, October 9, 2009, Cenk Çivici <cenk.civici@...> wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>                   Agree with Ted. This is referred to as Virtual Clock pattern.
> On Fri, Oct 9, 2009 at 7:05 PM, Ted Young <tedyoung@... <javascript:_e({}, 'cvml', 'tedyoung%40gmail.com');>> wrote:
>
>>
>>
>> This is pretty straightforward: any component or piece of code that needs
>> the current date and/or time should call a method on an object (either
>> injected or implemented as a singleton). That way during testing, you can
>> substitute the "real" time with a fake that returns whatever date or time
>> you want it to. For example:
>>
>> ...
>> public void doSomething(Clock clock) { // "inject" the clock
>> ...
>> Date now = clock.now();
>> ...
>> }
>>
>> or:
>>
>> public void doSomething() {
>> ...
>> Date now = Clock.instance().now(); // Clock is a singleton
>> ...
>> }
>>
>> Changing the time of the underlying system itself is not a good idea -- I
>> know I wouldn't want tests that I run to be changing the time on my
>> machine,
>> my appointment calendar would go crazy!
>>
>> ;ted
>>
>>
>> On Fri, Oct 9, 2009 at 12:44 AM, Inanc Gumus <inanc.gumus@... <javascript:_e({}, 'cvml', 'inanc.gumus%40gmail.com');><inanc.gumus%40gmail.com>>
>> wrote:
>>
>> >
>> >
>> > We'r running a system test that should test all of the components which
>> are
>> > distributed. But, we need to change the time for the testing to work as
>> > intended.
>> >
>> > What do you suggest? Should we change the system time of the machines
>> which
>> > components are running or should we tell components to change their
>> times?
>> > etc.?
>> >
>> >
>> >
>>
>> [Non-text portions of this message have been removed]
>>
>>
>>
>
> [Non-text portions of this message have been removed]
>
>
>
>
>
>
>
>    
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

--
http://www.natpryce.com

[Srdjan Todorovic]

On 10/10/2009, Chirag <cdadia@...> wrote:
> A link to Virtual Clock pattern
>
> http://c2.com/cgi/wiki?VirtualClock

Does anyone have a copy of the linked PDF file they could share, please?
The one on the wiki seems to be unreachable.

I have managed to open it using Google docs pdf viewer (probably from
Google cache) - but cannot seem to download.

Regards,
Srdjan