Isn’t the work you are doing when you test each private function separately?
tfwright
Asd
Well, if I calculate a rating like user.games_won / user.games_total, I need to test that it doesnt fail when user.games_total is zero.
Testing a private function looks like
result = Enum.to_list(calculate_rating([%{id: 1, games_won: 0, games_total: 0}]))
assert [%{id: 1, rating: 0}] = result
Testing this case from top_users would look like: I set up a mock server, which replies to an HTTP request with an encoded file, which contains a user which has games_total = 0 and then I pass it in the top_users(source_mock_server_url, 1) and take top one and compare.
And if some step in the pipeline above the calculate_rating fails, this test case would fail too
0
tfwright
I see, yes, you gain some benefits from isolation of those tests that helps pinpoint exactly where something went wrong, avoid duplicating setup etc. I guess for me those are not real pain points but you’ve convinced me if a team member wanted to do something like that it might make sense, but I would probably still want to segregate them from the “true” unit tests.
0
Schultzer
Yikes, perversive use of public functions in an obsessive quest of TDD, have you ever thought about performance and the cost of compiling public functions.
I hope you find some balance in your life. 
FWIW you can have a public api that calls private functions, the best of both worlds.
1
sodapopcan
Interesting, I know you weren’t talking to me but no, I never have! Not that it’s a problem for me but it’s a good thing to keep in mind.
FWIW you can have a public api that calls private functions, the best of both worlds.
Amusingly, I think this is the point almost every responder so far (including myself) was trying to express, each in their own very unique way 
2
dimitarvp
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.
3
katafrakt
BTW @hauleth wrote a package to test private functions years ago: GitHub - hauleth/ex_unit_embedded: Define ExUnit tests alongside your private functions to test them. · GitHub
No idea if it still works though.
0
hauleth
hauleth
Exactly that. Private functions should be used (because compiler theoretically can optimise them better, especially now with type tracking), however if you need to test them, then there is probably something wrong in your API.
0
Asd
There is no effect on performance based on function visibility. There were some reports that having a lot of public functions in a module slows down compilation time, but it actually has no effect on runtime performace, and if it does, it is a result of some limitation in current compiler implementation
Oh and
That type of optimizations is out of scope of current type-system work, I asked about that some time ago on the forum. I hope that at least the dot (.) operator will finally be optimized
0