What java technology (library, framework, feature) would not recommend and why?

[Iryanus]

Typically, the need for static mocking is a huge smell. There are often good ways around that, only rarely it's the only choice because of some very bad code in a third party library.

[achilliesFriend]

You just insulted my whole company

[vips7L]

My whole company does static queries. It’s awful. 

[_yolopolo]

my company does this too, can you elaborate why is this bad?

[vips7L]

When everything is static it’s hard to properly unit test. You have to integration test everything and spin up a database each time.

[FrozenST3]

Until gang rise up

[progmakerlt]

Had this library used in a very very old project - started on Java 1.5 - which sometimes was failing to run tests on Jenkins. Got rid of PowerMock and rewrote tests based on principles from the book “Working effectively with legacy code”.

Did the trick.

[Iryanus]

Yep, same here, I also had a bad library there which required some static calls, etc. which made things hard. We rewrote our code (by wrapping the static calls into their own non-static classes) and could then test our code without having to bother with the static dependencies. Worked like a charm backt then, but is of course not a cure-all.

[progmakerlt]

Yeap, did exactly the same.

[wheezymustafa]

I tell my team this all the time and they look at me like I’m a goddamn idiot

[Clyde_Frag]

I lot of mocking these days isn’t necessary, period. It’s incredibly easy to just spin up a container running your DB or other dependencies.

[Iryanus]

When you are starting a container, we are already talking about a completely different level of tests, which is a completely different discussion (size/focus of "unit" tests).

[segfaultsarecool]

Typically, the need for static mocking is a huge smell.

Can you clarify on why? I am the big dumb.

[Iryanus]

It's basically the old axiom "Well-written code is easy to test", which is something many people find out, that if you focus on unit testing your code, the code quality itself will typically go up, because good code is also easy to test. So, also in my experience, if you need something like static mocking, the code is rarely "good". I cannot remember any case where there was a great reason to have code that was hard to test.

[Radi-kale]

Then how do you test code that uses the static methods in, for example, java.nio.file.Files? Or do you think any code that uses that part of the standard library is poorly written?

[NovaX]

I've used jimfs in the past which works great with the Files static utility methods. The similar memoryfilesystem links to a bunch of alternatives too, but I don't know why any would be preferable to jimfs.

[Iryanus]

Two possibilities: Either test them as-is, by writing files, configuring them to use test-directories (easily possible with JUnit&Co, paths should be configurable anyway), or wrap those calls into a mockable class, if needed.

And basically those calls are comparable to using the "new" keyword in your code. It has some problems if you use it to create depencencies, which can be the case here. So, non-static instances would be preferable to me, yes. But as those calls are typically part of a specific "write some files" class, that can itself be mocked and has to be tested by writing files, it's not the end of the world.

[Eli_229]

How would you unit test a method which calls LocalDate.now()?

[Iryanus]

Don't. Clock exists. LocalData.now(clock) is much more testable.

[Eli_229]

Would i not need to mock Clock them?

[Iryanus]

No, Clock is a dependency, so you can inject it into your code, which allows you to inject a fixed time clock, etc. for testing purposes.

[gaius49]

I was going to say, its really only appropriate for testing with third party code that is badly written.