From the perspective of unit testing, the code under test should obviously not be accessing outside resources so the third party methods need to be mocked. However, it seems like this is poor practice because third party methods can change and become static/final which makes mocking difficult in Mockito. So in that sense, is it best practice to always wrap up third party methods?

I suppose this question may also apply to other programming languages and testing frameworks.

  • Yes; don't mock what you don't own, use facades to protect your code from third party API changes.
    – jonrsharpe
    Commented Jul 3, 2020 at 20:36

1 Answer 1


Should all third party methods that access outside resources (like other databases) be wrapped up?

Yes, pretty much. See Parnas, 1971. The core idea is that in our designs we create boundaries to insulate the bulk of our code from the specifics of our design decisions. In other words, we're writing our code in such a way that changing a design decision has only local impact.

When you do this, one of the useful consequences is that the boundary that you have created has a character that allows you to replace it with something simpler. Thus, we can introduce a test double to act as a substitute for our module in contexts where use of the module will be problematic (ex: in a test environment).

third party methods can change and become static/final

Yes. Notice, however, that changes to the third party methods will also be challenging on your production code unless you have taken steps to encapsulate it well.

Unstable dependencies create their own problems, which is why we avoid them when we can and take steps to limit the blast radius when we cannot.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.