Keith Hodges <keith_hodges at yahoo.co.uk> writes:
> Second
> Problem, I am struggling to work out how to test my new code fully.
> 
> 1. It turns out that the millisecondClockValue supplied by the vm, is
> one of those SmallInteger things which will roll over every once in a
> while. One needs to set up the scenario just before and after the roll
> over in order to see that everything is handled smoothly.
> 
> 2. I have organised this implementation around a call
> #milliSecondsSinceMidnight, and it is necessary to test that the
> transition from 23:59.59 to 00:00.00 also goes smoothly.
> 
> So within my test environment I have no control over the vm's
> millisecondClock. Secondly all of the interesting things, like timing
> offsets are stored in Class variables so my test code can't really
> mess with them. The best I can probably manage is to test the
> 'algorithm' and hope for the best. Any ideas?

Tough one!

You could modify the code to make this part replaceable.  If it is
just a few methods in question, you could give them an extra argument
which is the technique to use for reading the system clock.  By
default they could use millisecondClock, but your tests could replace
them with a mock object that returns repeatable, tricky clock values.


-Lex