This is a pretty straightforward way to test untestable code.This is a pretty straightforward way to test untestable code.

Testing the Untestable: A Simple Way to Handle Static Methods in Legacy Java

2025/10/24 12:22
2분 읽기
이 콘텐츠에 대한 의견이나 우려 사항이 있으시면 crypto.news@mexc.com으로 연락주시기 바랍니다

I'm currently working on a software designed more than a decade ago. It offers a plugin architecture: you can develop a plugin whose lifecycle is handled by the software. The tough part, though, is how you access the platform capabilities: via static methods on singletons.

@Override public boolean start() { var aService = AService.getInstance(); var anotherService = AnotherService.getInstance(); // Do something with the services var result = ...; return result; }

There's no easy way to test the start() method. In the old days, Mockito developers had pushed back against this feature, and the only alternative was PowerMock. The decision was reversed in 2020 with the 3.4.0 release, which introduced static method mocking in Mockito.

I liked the previous situation better. My opinion is that having to mock static methods is a sign of badly designed code. I wrote about it already ten years ago. With PowerMock, one could mock the static methods, write the test, redesign the code, and then remove PowerMock. With the current situation, one can't look at the dependencies to search for design smells. In any case, the above problem still stands, and I can't change the design. It's forced upon me.

The solution is strangely straightforward, though. Just write a wrapper method around the one:

@VisibleForTesting //1 boolean start(AService aService, AnotherService anotherService) { //2 // Do something with the services var result = ...; return result; } @Override public boolean start() { var aService = AService.getInstance(); var anotherService = AnotherService.getInstance(); return start(aService, anotherService); //3 }

  1. Method is normally private, but since we want to test it, we make it package visible. The @VisibleForTesting annotation is for documentation purposes.
  2. The testable method has parameters that can be mocked
  3. Call the testable method

In this post, I showed how one can test legacy code not built on Dependency Injection. This is a pretty straightforward way to test untestable code.


Originally published at A Java Geek on October 19th, 2025

면책 조항: 본 사이트에 재게시된 글들은 공개 플랫폼에서 가져온 것으로 정보 제공 목적으로만 제공됩니다. 이는 반드시 MEXC의 견해를 반영하는 것은 아닙니다. 모든 권리는 원저자에게 있습니다. 제3자의 권리를 침해하는 콘텐츠가 있다고 판단될 경우, crypto.news@mexc.com으로 연락하여 삭제 요청을 해주시기 바랍니다. MEXC는 콘텐츠의 정확성, 완전성 또는 시의적절성에 대해 어떠한 보증도 하지 않으며, 제공된 정보에 기반하여 취해진 어떠한 조치에 대해서도 책임을 지지 않습니다. 본 콘텐츠는 금융, 법률 또는 기타 전문적인 조언을 구성하지 않으며, MEXC의 추천이나 보증으로 간주되어서는 안 됩니다.

Roll the Dice & Win Up to 1 BTC

Roll the Dice & Win Up to 1 BTCRoll the Dice & Win Up to 1 BTC

Invite friends & share 500,000 USDT!