In any codebase there are places that are that bit harder to test. If you are testing after the fact, and trying to cover as much code as possible, testing private methods can be a very appealing tool.
✅ Always test through the public interface of an object.
❌ Never test private methods directly.
Let’s take a look at how private methods arrive in our codebase.
Private methods are extracted from the public methods. This happens for one of two reasons.
- To make the public method easier to understand, by extracting well named private methods.
- To remove duplication across the public methods.
In both these cases private methods are integral to public methods successfully doing their job. All application code that interacts with an object does so through the public interface and our tests should be mimicking that behaviour too.
Therefore tests should only interact with an object’s public interface.
Why write these kinds of tests?
When there is a lot happening in a class, and you have to add one little piece of functionality that is getting complex and you need to get it tested. This is where the little devil on your shoulder whispers, “use send.”
In the example below, the
BankAccountPresenter receives a hash of
account_data, and the
payload method returns a number of fields based on that data for use in the UI. At this point, our task is to calculate the total savings across a number of bank accounts and expose
:total_savings in the response from the
Above you can see our tests cover both
payloadreturning a stubbed result for the
- and a specific test on the private
Why not fake private methods?
Here the tests don’t exercise the public and private methods working together which raises two points:
- Can the code be relied upon at runtime?
- Given the private methods are extracted from the public methods, they should be easy to refactor with the supportive tests already in place, rather than tests that are brittle and need updating every time a private method has its name, parameter list or behaviour updated.
Building on point 2, anytime the source code changes, of course tests will need to change. However, we should be able to test via the public interface, providing a safe, reliable safety net and feedback loop and minimise the impact of a code change that results in an unnecessary proliferation of test failures.
A Code Smell is an indicator that there is something not-quite-right about the design of our code and should seek to refactor to a simpler, easier to test, solution.
With tests being harder to write, it is usually due to surrounding code being too complex.
Testing a private method directly is a Code Smell. Ruby has many powerful language features. Here, the use of
send can be an indicator of tests directly calling a private method.
Usually this is done as the only way to test the functionality, which suggests the code is missing an abstraction. In our example this is not the case.
The updated code below demonstrates testing can be achieved with less overhead using the public interface.
There is no:
- stubbing of the private method,
- direct testing of the private method.
Leaving one single test that will fail if any future breaking change is made to