[joelbluminator]

Let's say I have a class called User and in it a method that says the current time. So User#say_current_time which simply accesses the Date class (it takes no arguments).

Can you show me how you would mock the current time of that method in Java?

It's one line of Ruby/Javascript code to do that.

[Jach]

Without using a mock framework, assuming User#say_current_time isn't a private or static method then:

    final Date testDate = someFixedDate;
    User testUser = new User() {
        @Override
        Date say_current_time() {
            return testDate;
        }
    };

If it is private and/or static, you can get around it without having to change the code, but if you own the code, you should just do that... Often the change will be as simple as replacing some method's raw usage of Date.now() with a local say_curent_time() method that uses it or some injected dependency just so you can mock Date.now() without hassle.

But your point further down that in Java you have to think about your code structure more to accommodate tests is valid. I think it's easy to drink the kool-aid and start believing that many code structuring styles that enable easier testing in Java are actually very often just better styles regardless of language, but you're not going to really see the point if you do nothing but Ruby/JS where you can get away with not doing such things for longer. Mostly it has to do with dynamic languages offering looser and later and dynamic binding than static languages (which also frequently makes them easier to refactor even if you don't have automated tools). One big exception is if your language supports multiple dispatch, a lot of super ugly Java-isms go away and you shouldn't emulate them. The book Working Effectively with Legacy Code is a good reference for what works well in Java and C++ (and similar situations in other languages), it's mostly about techniques for breaking dependencies.

[throwaway_fjmr]

I am assuming this is easier in Ruby because you can monkey patch classes?

Mockito in Java has a nifty way of doing this with Mockito.mockStatic:

  @Test
  public void mockTime() throws InterruptedException {
    LocalDateTime fake = LocalDateTime.of(2021, 7, 2, 19, 0, 0);

    try (MockedStatic<LocalDateTime> call = Mockito.mockStatic(LocalDateTime.class)) {
      call.when(LocalDateTime::now).thenReturn(fake);

      assertThat(LocalDateTime.now()).isEqualTo(fake);
      Thread.sleep(2_000);
      assertThat(LocalDateTime.now()).isEqualTo(fake);
    }

    LocalDateTime now = LocalDateTime.now();
    assertThat(now).isAfter(fake);
    assertThat(now).isNotEqualTo(fake);
  }

Or you can pass a Clock instance and use .now(clock). That Clock then can be either a system clock or a fixed value.

[joelbluminator]

> I am assuming this is easier in Ruby because you can monkey patch classes?

Yes, that was my point. I see it's possible in Java though, hurts my eyes a bit but possible :)

[mypalmike]

I'll take clean contractual interfaces (aka actual principle of least surprise) over "I can globally change what time means with one line of code!" on large projects every time.

[lkitching]

If you want to use DI, in java 8 you could inject a java.time.Clock instance in the constructor and provide a fixed instance at the required time in your test e.g.

    Instant testNow = ...
    User u = new User(Clock.fixed(testNow, ZoneOffset.UTC));
    u.sayCurrentTime();

although it would be better design to have sayCurrentTime take a date parameter instead of depending on an external dependency.

[joelbluminator]

Yes that was my point. You don't need DI or to structure your code any differently in Ruby/JS/Python. You just mock a method.

[lkitching]

In my experience the need to mock out individual methods like this is an indication that the code is badly structured in the first place. The time source is effectively a global variable so in this example you'd want to pass the time as a parameter to `sayCurrentTime` and avoid the need to mock anything in the first place. A lot of C#/java codebases do seem to make excessive use of mocks and DI in this way though.

[hota_mazi]

    User mock = mock(User.java)
    when(mock.say_current_time()).thenReturn(someDate)

[joelbluminator]

OK. first I could be ignorant about Java since I haven't touched it in more than a decade. Which library is doing that? And also what is mock(User.java) returning - is it an actual User instance or a stub? I want a real User instance (nothing mocked in it) with just the one method mocked.

And again if this is possible I will admit ignorance and tip my hat at the Java guys.

[hota_mazi]

It's Mockito [1], which has been a standard for a while. There are other libraries and they use different strategies to provide this kind of functionalities (dynamic proxies, bytecode weaving, annotation processing, etc...).

[1] https://site.mockito.org/

[joelbluminator]

And ... is the whole user being mocked or just the method?

[vincnetas]

It creates a stub, but you can also configure it to pass any method calls to original implementation. You should be tiping your hat i think.

https://javadoc.io/static/org.mockito/mockito-core/3.11.2/or...

User mock = mock(User.java)

Should have been

User mock = mock(User.class)

[hota_mazi]

Ah oops, I've been writing exclusively Kotlin for several years, my Java is becoming rusty (no pun intended).

[throwaway_fjmr]

I think what you want is a "spy" (partial mock), not a full "mock", but yes, both are possible. You can partially mock classes, i.e., specific methods only. Syntax is almost the same, instead of mock(User.class) you write spy(User.class).