You could start a holy war with questions like this!

I’m a TDDer myself and I do not see value in testing private functions in that they mostly appear later as I’m refactoring. However, sometimes you can find yourself with a single function that does a lot of stuff. In those cases, you can always move these function to a sub “private” module (@moduledoc false) and write tests for them there (though personally when I do this I just end up deleting the tests when I’m done as I just want tests for my public interface).

In the case of your example, that is a candidate to just be moved to an external helper module. It’s one of those functions that does one small thing very well, so there’s no harm in other people using it, especially since it has tests! However, if you really want to keep it private in your current module, then the tests for whatever public function you are using this for will certainly cover it. If you really want to start with just a test for that one line, then I’d do what I suggested above (and sanctioned by Sandi Metz herself ;)), make it public, write a test for it and when you’re done, or at least when you have public functions that consume it, delete the test and make it private.

Otherwise, keeping tests for things at this level of granularity makes reafactorting a massive pain. It’s also exhausting for readers (although I guess no one reads code anymore and LLMs don’t get exhausted /s)

I don’t think this is unquestionably true. Maybe debatable, but I’d strongly argue that one of the underrated benefits of unit tests is that they document what a module does. If you maintain tests for private functions you are now also documenting how it does it. Not terrible, but why do that when you can write a test for the caller than exercises the private function?

Private functions to me should be:

• An implementation detail;
• A way to enforce boundaries.

If you find yourself needing to test private functions then it’s time to ask yourself or the team these questions:

• Is it time to promote these functions into a public API and accept that any other module in the app can call them now?
• Are you getting obsessive about testing every single thing? Indeed testing the public API and letting a private function fail an assertion as a part of that test is quite fine and not a reason to make private functions public.

I don’t agree with the argument that only libraries should carefully control what’s public. I’m currently working hard, together with Claude, to untangle quite the spaghetti code. It’s painful and it really drives home the point that scope and access creep are real problems.