Testing the untestable

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 m…


This content originally appeared on DEV Community and was authored by Nicolas Frankel

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


This content originally appeared on DEV Community and was authored by Nicolas Frankel


Print Share Comment Cite Upload Translate Updates
APA

Nicolas Frankel | Sciencx (2025-10-23T09:02:00+00:00) Testing the untestable. Retrieved from https://www.scien.cx/2025/10/23/testing-the-untestable/

MLA
" » Testing the untestable." Nicolas Frankel | Sciencx - Thursday October 23, 2025, https://www.scien.cx/2025/10/23/testing-the-untestable/
HARVARD
Nicolas Frankel | Sciencx Thursday October 23, 2025 » Testing the untestable., viewed ,<https://www.scien.cx/2025/10/23/testing-the-untestable/>
VANCOUVER
Nicolas Frankel | Sciencx - » Testing the untestable. [Internet]. [Accessed ]. Available from: https://www.scien.cx/2025/10/23/testing-the-untestable/
CHICAGO
" » Testing the untestable." Nicolas Frankel | Sciencx - Accessed . https://www.scien.cx/2025/10/23/testing-the-untestable/
IEEE
" » Testing the untestable." Nicolas Frankel | Sciencx [Online]. Available: https://www.scien.cx/2025/10/23/testing-the-untestable/. [Accessed: ]
rf:citation
» Testing the untestable | Nicolas Frankel | Sciencx | https://www.scien.cx/2025/10/23/testing-the-untestable/ |

Please log in to upload a file.




There are no updates yet.
Click the Upload button above to add an update.

You must be logged in to translate posts. Please log in or register.