Testing code that depends on today's date

[Per Jacobsson]

Hi,
This has been annoying me for a while and I can't think of a clean solution for it. Hope this makes sense: I have some code that returns different results depending on what today's date is (the number of days since a user first registered, etc). The simple approach is to just create a new instance of java.util.Date whenever I need to know the current date, but that tends to make both unit and automated functional testing difficult.

I'm currently injecting today's date into the classes that need it, and then the tests can just use a static date. It gets pretty ugly though, a lot of times this date has to be dragged along deep into the domain model.

An alternative would be to take the old school approach and have a static factory that everything that needs to know today's date calls, and allow the unit tests to override with a test date. Of course, then you run into all the other issues that dependency injection solves.

Any thoughts?
Thanks,
/ Per



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

[Andrew McDonagh-6]

Hi,

If you use the Abstract Factory pattern to create the Date() object
instance, instead of calling new Date() yourself or passing it around,
then the production TodaysDateConcreteFactory can simply :

return new Date();


Whereas during your unit or functional tests, you use a
MockTodaysDateConcreteFactory object, which returns what ever you want

return expectedDate;

Hope this helps

Andrew


2008/6/17 Per Jacobsson <perjacobsson@...>:

> Hi,
> This has been annoying me for a while and I can't think of a clean solution
> for it. Hope this makes sense: I have some code that returns different
> results depending on what today's date is (the number of days since a user
> first registered, etc). The simple approach is to just create a new instance
> of java.util.Date whenever I need to know the current date, but that tends
> to make both unit and automated functional testing difficult.
>
> I'm currently injecting today's date into the classes that need it, and then
> the tests can just use a static date. It gets pretty ugly though, a lot of
> times this date has to be dragged along deep into the domain model.
>
> An alternative would be to take the old school approach and have a static
> factory that everything that needs to know today's date calls, and allow the
> unit tests to override with a test date. Of course, then you run into all
> the other issues that dependency injection solves.
>
> Any thoughts?
> Thanks,
> / Per
>
> [Non-text portions of this message have been removed]
>
>

[Per Jacobsson]

That would work, but I wouldn't be really happy about going back to the old singleton factory pattern. It may just be the best fit for this case though.
/ Per
________________________________________
From: junit@... [junit@...] On Behalf Of Andrew McDonagh [andrewmcdonagh@...]
Sent: Tuesday, June 17, 2008 4:20 PM
To: junit@...
Subject: Re: [junit] Testing code that depends on today's date

Hi,

If you use the Abstract Factory pattern to create the Date() object
instance, instead of calling new Date() yourself or passing it around,
then the production TodaysDateConcreteFactory can simply :

return new Date();

Whereas during your unit or functional tests, you use a
MockTodaysDateConcreteFactory object, which returns what ever you want

return expectedDate;

Hope this helps

Andrew

2008/6/17 Per Jacobsson <perjacobsson@...<mailto:perjacobsson%40eharmony.com>>:

> Hi,
> This has been annoying me for a while and I can't think of a clean solution
> for it. Hope this makes sense: I have some code that returns different
> results depending on what today's date is (the number of days since a user
> first registered, etc). The simple approach is to just create a new instance
> of java.util.Date whenever I need to know the current date, but that tends
> to make both unit and automated functional testing difficult.
>
> I'm currently injecting today's date into the classes that need it, and then
> the tests can just use a static date. It gets pretty ugly though, a lot of
> times this date has to be dragged along deep into the domain model.
>
> An alternative would be to take the old school approach and have a static
> factory that everything that needs to know today's date calls, and allow the
> unit tests to override with a test date. Of course, then you run into all
> the other issues that dependency injection solves.
>
> Any thoughts?
> Thanks,
> / Per
>
> [Non-text portions of this message have been removed]
>
>

[kentb]

I wouldn't think first of making the Calendar (a thing that makes Dates) a
global variable (i.e. "singleton"). I'd rather pass it everywhere it is
needed.
 
Cheers,
 
Kent Beck
Three Rivers Institute

  _____  

From: junit@... [mailto:junit@...] On Behalf Of Per
Jacobsson
Sent: Tuesday, June 17, 2008 9:17 PM
To: junit@...
Subject: RE: [junit] Testing code that depends on today's date



That would work, but I wouldn't be really happy about going back to the old
singleton factory pattern. It may just be the best fit for this case though.
/ Per
________________________________________
From: junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
[junit@yahoogroups. <mailto:junit%40yahoogroups.com> com] On Behalf Of
Andrew McDonagh [andrewmcdonagh@ <mailto:andrewmcdonagh%40gmail.com>
gmail.com]
Sent: Tuesday, June 17, 2008 4:20 PM
To: junit@yahoogroups. <mailto:junit%40yahoogroups.com> com
Subject: Re: [junit] Testing code that depends on today's date

Hi,

If you use the Abstract Factory pattern to create the Date() object
instance, instead of calling new Date() yourself or passing it around,
then the production TodaysDateConcreteFactory can simply :

return new Date();

Whereas during your unit or functional tests, you use a
MockTodaysDateConcreteFactory object, which returns what ever you want

return expectedDate;

Hope this helps

Andrew

2008/6/17 Per Jacobsson <perjacobsson@ <mailto:perjacobsson%40eharmony.com>
eharmony.com<mailto:perjacobsson%40eharmony.com>>:
> Hi,
> This has been annoying me for a while and I can't think of a clean
solution
> for it. Hope this makes sense: I have some code that returns different
> results depending on what today's date is (the number of days since a user
> first registered, etc). The simple approach is to just create a new
instance
> of java.util.Date whenever I need to know the current date, but that tends
> to make both unit and automated functional testing difficult.
>
> I'm currently injecting today's date into the classes that need it, and
then
> the tests can just use a static date. It gets pretty ugly though, a lot of
> times this date has to be dragged along deep into the domain model.
>
> An alternative would be to take the old school approach and have a static
> factory that everything that needs to know today's date calls, and allow
the

> unit tests to override with a test date. Of course, then you run into all
> the other issues that dependency injection solves.
>
> Any thoughts?
> Thanks,
> / Per
>
> [Non-text portions of this message have been removed]
>
>

 


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

[Nat Pryce]

There are two things you can do.  A) separate code that performs
calculations on dates from the code that gets the current date.  B)
get the current date get it through an abstract interface.

E.g. suppose I have a method like...

   Money currentValue() {
       Date today = new Date();
       ...
   }

I'd turn that into:

    Money valueAt(Date date) {
        ...
    }

and have another object decide what date to pass in.

That other object can get the date through an abstract interface. (I
usually call that interface "Clock" to avoid confusion with the
existing java.util.Calendar class).  I find its usually one of the
first things I write on every project -- if only it was in the
standard library.

I find that separating calculation with dates from the choice of date
to use means I don't have to pass the clock around everywhere.  It
also makes the code more flexible.  It can, if asked to, implement
what-if calculations without major redesign, for example.

--Nat


2008/6/17 Per Jacobsson <perjacobsson@...>:

> Hi,
> This has been annoying me for a while and I can't think of a clean solution
> for it. Hope this makes sense: I have some code that returns different
> results depending on what today's date is (the number of days since a user
> first registered, etc). The simple approach is to just create a new instance
> of java.util.Date whenever I need to know the current date, but that tends
> to make both unit and automated functional testing difficult.
>
> I'm currently injecting today's date into the classes that need it, and then
> the tests can just use a static date. It gets pretty ugly though, a lot of
> times this date has to be dragged along deep into the domain model.
>
> An alternative would be to take the old school approach and have a static
> factory that everything that needs to know today's date calls, and allow the
> unit tests to override with a test date. Of course, then you run into all
> the other issues that dependency injection solves.
>
> Any thoughts?
> Thanks,
> / Per
>
> [Non-text portions of this message have been removed]
>
>

[Steve Freeman-4]

It's interesting how introducing time properly as part of the domain  
model helps make the code clearer. On most projects, I find what's  
actually needed is a Date (as in a day) rather than a Date (as in a  
Timestamp) which Java confuses, so it's worth declaring project-
specific time types -- or at least using Joda date.

S.

On 18 Jun 2008, at 08:26, Nat Pryce wrote:

> There are two things you can do.  A) separate code that performs
> calculations on dates from the code that gets the current date.  B)
> get the current date get it through an abstract interface.
>
> E.g. suppose I have a method like...
>
>   Money currentValue() {
>       Date today = new Date();
>       ...
>   }
>
> I'd turn that into:
>
>    Money valueAt(Date date) {
>        ...
>    }
>
> and have another object decide what date to pass in.
>
> That other object can get the date through an abstract interface. (I
> usually call that interface "Clock" to avoid confusion with the
> existing java.util.Calendar class).  I find its usually one of the
> first things I write on every project -- if only it was in the
> standard library.
>
> I find that separating calculation with dates from the choice of date
> to use means I don't have to pass the clock around everywhere.  It
> also makes the code more flexible.  It can, if asked to, implement
> what-if calculations without major redesign, for example.
>
> --Nat
>

Steve Freeman
http://www.mockobjects.com

Winner of the Agile Alliance Gordon Pask award 2006

[Mike Hill-6]

The 'today' issue is a well established annoyance.  A simple extract
method on the logic code to separate it from the today-fetching code
is really all that's needed.

I don't usually write a fake clock.  I do usually have some handy
utility laying around that lets me easily do the +30 days, etc.  Thus
my test case takes a 'now' and manipulates it to construct the test
data.  Of course, the stuff that's actually executed on the if branch
is itself already extracted and testable through the direct
invocation.  I wind up with two tests, one against the predicate, one
against the branch body.

This is one of those things, like, say, quickly dropping the command
pattern into a controller, that you eventually begin to do *as you
roll the code*, without much design-ish thinking.  At my house we have
a motto, based on the truly extraordinary number of times I have badly
bashed my head while fetching firewood from the triangle under the
stairs where we keep it:  "Fool me once, shame on you.  Fool me three
hundred and fourteen consecutive times, shame on me."  I now crouch
throughout the process.

Have fun!
Hill
Want to learn TDD fast?  <http://www.industriallogic.com/elearning>

[J. B. Rainsberger-2]

On 2008-06-17, at 11:28 , Per Jacobsson wrote:

> Hi,
> This has been annoying me for a while and I can't think of a clean  
> solution for it. Hope this makes sense: I have some code that  
> returns different results depending on what today's date is (the  
> number of days since a user first registered, etc). The simple  
> approach is to just create a new instance of java.util.Date whenever  
> I need to know the current date, but that tends to make both unit  
> and automated functional testing difficult.
>
> I'm currently injecting today's date into the classes that need it,  
> and then the tests can just use a static date. It gets pretty ugly  
> though, a lot of times this date has to be dragged along deep into  
> the domain model.
>

I'm surprised by this. In a typical web application, I'd expect a  
design similar to this:

1. HTTP Request Handler gets current date from system clock or HTTP  
request header; calls application request handler (or Controller or  
Service), passing the current date

2. Application request handler determines which model class to invoke;  
calls its business method, passing the current date

3. You've finished!

By step 3, I would imagine that model classes are passing the date  
around, which I find quite normal. You might want to refactor in there  
a little, possibly by introducing a domain class that represents the  
way you interpret that date.
> An alternative would be to take the old school approach and have a  
> static factory that everything that needs to know today's date  
> calls, and allow the unit tests to override with a test date. Of  
> course, then you run into all the other issues that dependency  
> injection solves.
>
I used to do this, and even contributed to the Virtual Clock paper,  
but I now favor passing the date around. I call it the Instantaneous  
Request pattern: the system pretends that the entire request happens  
in an instant, by taking a snapshot of the clock upon receiving the  
request, then passing the date along as needed.

Of course, as I read the remaining messages in this thread, I might  
have difference advice for you. :)
----
J. B. (Joe) Rainsberger :: http://www.jbrains.ca
Your guide to software craftsmanship
JUnit Recipes: Practical Methods for Programmer Testing
2005 Gordon Pask Award for contributions to Agile Software Practice