• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

unit tests and time dependencies

 
Sheriff
Posts: 7023
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In a recent thread, Andy Hunt stated that tests should not rely "on anything that isn't under your direct control (like the time ...)."
Typically, I'll read such statements and my mind will quickly add caveats such as, "except when the behavior is time dependent, in which case the setup for the test should control the time," and I'd be content that I've understood things. But perhaps I don't understand something.
If the behavior of some part of a system depends on the current time, then is there an alternative to controlling the time, as far as the test is concerned?
[ February 19, 2004: Message edited by: Dirk Schreckmann ]
 
author and iconoclast
Posts: 24207
46
Mac OS X Eclipse IDE Chrome
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi Dirk,
If I may: this is another instance where test-driven design would help. If you need to manipulate time in a test, then the application's access to time information has to be mockable. You'd write the application to call myTimeSource.getTime() instead of System.currentTimeMillis(), and myTimeSource.getDate() instead of new Date(), etc. where myTimeSource is some instance of an interface TimeSource that you define. Then the test can just provide its own TimeSource implementation to make time appear to pass in whatever manner is necessary for the test.
Now, you can't test response times this way -- but those would be functional tests, not unit tests.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Along the same lines I have been wondering about tests for a class that extends java.util.TimerTask and impliments the abstract run method. I know that tests are supposed to run quickly - but I have been using Thread.sleep in the test to allow time for the run method to be called by the "Timer" that it is scheduled with. Because I want the run method to update a instance variable each minute, since this is a time tracking app, the tests have to run for at least a minute. More if I want to test that only one task can be active at a time. I don't see any way around this. Is this the correct way to go about testing? Using TDD I haven't found that I need a method to set the delay and period for Timer.scheduleAtFixedRate to anything other than 60000 milliseconds. This is my first post so please let me know if I should have posted elsewhere.
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Patrick, I see two options here:
1) Put your 1-minute test into a set of "slow running" tests, which get executed more rarely (compared to your "these I'm working on right now" set of tests).
2) Make the "60 seconds" configurable. I know it isn't needed to implement the functionality, but it's sometimes an exception worth of doing -- to make testing easier.
 
author & internet detective
Posts: 41919
910
Eclipse IDE VI Editor Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Patrick,

Using TDD I haven't found that I need a method to set the delay and period for Timer.scheduleAtFixedRate to anything other than 60000 milliseconds.


Or you could use TDD to see the "need" to set the time. You want a test that schedules a fixed rate. To me the signature the test is asking for is: scheduleAtFixedRate(long numMillis). Then scheduleAtFixedRate() for 60 seconds could be the exposed public method.
This could be a package private method if you don't want to expose it. But if you do choose to expose it, you have a more generic class.
reply
    Bookmark Topic Watch Topic
  • New Topic