Why not write unit tests for the internal interface?

The core concept of test-driven development (tdd,test Driven Development) is to make refactoring (refactoring) more effective, rather than creating more tests.

For a project with a long life cycle, in its first version, it usually has a good, clean architecture. As the version continues to update, more and more heterodoxy workarounds (hacky Workaround), shortcuts (short Cuts), inconsistent interfaces (inconsistent interfaces), hard-to-understand contracts are introduced ( Confusing contracts) and so on, the project becomes more and more difficult to maintain (especially our outdated code). So, how can we avoid this situation? The key is that the project code has the ability to refactor freely without introducing regression (regression). This capability is provided by test-driven development.

Based on this understanding, we should write unit tests as a tool for code refactoring. What do you mean? The first principle of test cases: When refactoring code, you should not change unit tests .

Considering the opposite situation, when we try to refactor the project code, we modify some of the interfaces that the unit tests depend on. So we need to modify the code of the unit test synchronously. So how can we be sure that regression is not produced in unit tests? This kind of unit test, not only can not help the code refactoring, but become a burden. This is also a problem with many of our outdated tests: when we change the source code, it takes a lot of time to update the test.

That's why one of the best practices is "write unit tests for public interfaces only"interface. The public interface is usually relatively more stable (otherwise it affects the user). If the unit tests are for the internal interface, the refactoring will either not change these interfaces or the test code must be modified synchronously.

Why not write unit tests for the internal interface?