Mock Around the Clock – Java Code Geeks

[ad_1]

When i produced System stubs I have attempted, and failed, to produce a dummy implementation for the system clock.

It is very convenient in production code to create a variable containing something like DateTime.now() then perform time calculations between that instant and another date.

How do you care for the tests?

I will try to surprise you by telling you that in my experience most attempts to poke fun at the above in Java are unsuccessful.

In other languages, it may be possible to inject alternative behavior into the global get function for the time being. When possible, this is a great solution.

At some point, I might figure out how to intercept calls to System.currentTimeMillis() in Java and produce the ClockMock I really want to produce … but until then:

Stop trying to make fun of the current time in Java with an abstraction!

Why can’t I laugh at the present time?

You can.

But you just said …

I said not to introduce abstraction. Introducing a known time value into an algorithm that calculates time is acceptable. But the introduction of wide distribution time catcher abstraction is not.

Consider the following:

int getDriverAge(Date dateOfBirth, TimeGetter timeGetter) {
   return roundToWholeYears(daysSince(dateOfBirth, timeGetter));
}

int daysSince(Date date, TimeGetter timeGetter) {
   Date now = timeGetter.getNow();

   // return days between date and now
}

In the example above, the TimeGetter has spread through a few functions. How many other levels above did this abstraction of now() is it only there so that a test can replace it with a mock-up?

Let this be my makeup TimeGetter where Java is integrated Clock or any number of other things, this pattern sucks. The ability to abstract time becomes a virus in software.

Likewise, trying to use a global singleton that is mocking creates a need to verify that no one is bypassing MockableTime.now() with the real one now() function.

So how do we test the weather?

Two things.

  1. Use Fuzzy assertions for the time when doing further testing – don’t worry about the exact release time if it’s not necessary / predictable in real life.
  2. Definitely test any algorithm that depends on actual dates by making sure its public interface allows all date input (including now) transmitting.

This means that the most low-level-implementation should not call himself now() but should just process the time data.

A little higher, we know that the code can pass safely now() down to the lower level code, and we don’t have to worry about predicting the response.

Our tests at a higher level may use fuzzy assertions that verify either is it a timestamp Where is it a timestamp within a certain range – as long as it does not lead to too much Competitive calculation test.

TL; DR

Creating an abstraction for something as global and simple as time can create a virus throughout the codebase, where loads of modules suddenly need to know something that is really just a hook. for testing.

Choosing your battles carefully can lead to the low-level code not picking up the time itself, which makes testing easier, and higher-level code testing doesn’t care too much about the precise times of the results, because they are already covered by lower level tests.

Posted on Java Code Geeks courtesy of Ashley Frieze, partner of our JCG program. See the original article here: Mock up around the clock

The opinions expressed by contributors to Java Code Geeks are their own.

[ad_2]

Source link