Should I expose private methods just so tests can call them?

Usually no. Making a private method public for tests solves the wrong problem: it changes your production API to suit the test harness. A better default is to test through the public contract, then extract hidden logic into a real component if the public path is too awkward. A narrow internal seam can be acceptable, but broad public exposure usually buys short-term convenience at the cost of long-term API and test maintenance, as the Google Testing Blog on preferring public APIs and the Google Testing Blog on testing behavior, not implementation both argue.

What should the test boundary be?

Start with the boundary your real callers use: a public method, module API, command, or HTTP endpoint. If you refactor internals but keep user-visible behavior the same, your assertions should usually stay the same too. That is the maintainability gain behind testing behavior instead of internal structure. The 2013 Google article says that in most cases, tests should focus on your code’s public API rather than exposing implementation details.

When should hidden logic become its own component?

If driving a rule through the public path requires bloated setup, that is often a design signal, not a testing inconvenience. The hidden logic may deserve its own named responsibility.

Consider this progression:

Before:
InvoiceService.finalize(invoice)
  -> validate(invoice)
  -> computeTax(invoice, region, exemptions)
  -> persist(invoice)

If computeTax contains dense jurisdiction rules, do not make it public on InvoiceService just for tests. Extract it:

After:
InvoiceService.finalize(invoice, taxCalculator)
TaxCalculator.compute(invoice, region, exemptions)

Now you can test InvoiceService.finalize for observable outcomes and test TaxCalculator.compute directly because it is no longer a private helper; it is a cohesive component with its own contract.

Why is exposing a private method usually a bad trade?

First, you create API debt. Public methods invite accidental callers and compatibility expectations.

Second, you couple tests to call layout rather than outcome. The 2013 article explains that existing tests should not need to change when only implementation changes. A helper turned public pushes you the other way.

Third, you can get false confidence. The 2015 article warns that a behavior tested only through an implementation-detail class may still fail when exercised through the real public API.

Is a narrow test seam ever acceptable?

Yes, but define the boundary clearly. Use the smallest contained seam your language offers, such as package-private visibility or an internal-only helper module. The key ordering is design first, seam second: decide that callers must still go through the production entry point, then add limited access only where extraction is not yet worth the change.

A quick checklist:

• Can I verify this through the real public behavior?
• Does this logic have a meaningful name and responsibility of its own?
• Would making it public create an API no production caller should use?
• Am I asserting an internal call sequence instead of an observable outcome?

If you answer yes to the third or fourth question, do not publish the helper as public API.

What about generated code?

Usually test the code that depends on it, or test the generator’s outputs and contract. Do not widen generated internals just to satisfy unit tests.

What if I need faster feedback before a refactor?

Add the smallest internal seam you can remove later, and write down the intended boundary: external callers stay on the public API; the seam exists only to unblock coverage while you extract the real component.

Next step: inspect one test that is pushing you toward public, and choose explicitly between a behavior-level assertion, a new cohesive component, or a temporary internal seam.

Reviewed: 2026-09-05.