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

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

Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact service@support.mexc.com for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.
Share Insights

You May Also Like