This article was originally posted on LinkedIn.
Would you feel comfortable allocating your personal time to solving engineering use cases such us mocking private or static methods? I don’t feel too comfortable, but I’m pushing forward. Neither private or static methods should be ever mocked. Instead, engineers should write clean code and wrap legacy code with an abstraction layer.
Life is a sequence of experiments, leading to learning, leading to more experiments.
Helping Powermock to integrate cleanly with Mockito is an experiment. We will see how it impacts our point of view on testing legacy code, our skills in engineering changes across 2 separate Open Source projects, and our community, which will be given more powerful test tools.
The more powerful test tools are, the more awkward code can be written without punishment.
If something is hard to test, it’s a punishment for poorly designed, untestable code. That punishment is a strong signal to refactor the code. If the punishment is gone, as well can the refactoring.
We are getting really close to finalize Mockito API improvements that will enable clean static mocking with Powermock (hmmm, is there such thing as ‘clean static mocking’? :). Mockito is opinionated and for the time being we don’t plan to provide static mocking out of the box. However, Mockito will have flexible API so that frameworks like Powermock can cleanly integrate and offer features needed for testing legacy code.
After a long effort with Arthur Zagretdinov, the remaining problem was mocking constructors. At first it appeared as a really hard problem to tackle because the entire Mockito API was geared towards mocking methods and not constructors. Changing the API to work on higher abstraction than a Java method would mean a lot of rework and public API changes. Solution: create a sweet little interface that can adapt constructors to methods!
The work continues in GitHub ticket 1110. I predict that sometime in Q3 2017, the community will get clean static mocking with Mockito.
