Hi everyone,
I have a module with several public api and the implementation for these public require call to several private functions. Something like this
def foo do
bar
baa
baz
end
defp baa do
...
end
defp baz do
...
end
defp bar do
.....
end
And baa have 2 cases to test, baz have 3 cases, and bar have 5 cases. So if I just keep them as private functions inside 1 module, I need to write 2x3x5=30 unit tests.
So I refactor them to separate module and make them public so I just need to write 2+3+5=10 unit tests and some smoke tests for foo which don’t cover all the scenarios.
Is that approach ok and how I prevent users from misused my private module ? I just want the user to use my public module only.
The convention is that internal modules are @moduledoc false, similar how internal functions are @doc false, though you have no way to enforce that no one will use them.
There is some prototype library defmodulep which hides modules by name doing some name mangling, but still, once someone figured out the mangled name, they can use the module anyway.
I wonder if boundaries will end up being the way to solve this in future. Make the functions public but enforce that only the parent module can call them outside of tests.
There is no way of really enforcing that in the BEAM, as there are no parent/child relationships between modules. All of those tools rely on mangling and aliasing module names.
And if you know the mangled name, you can use anything in that module.
It can already solve it today Add use Boundary to the top-level module (e.g. context), and the cross-boundary calls to the internal ones will be reported. It’s still not fully usable, b/c the support for nested boundaries is lacking, but that’s definitely on the roadmap.
Boundary doesn’t do any mangling. It uses compilation tracer to collect all function/macro invocations, and then reports non-permitted cross-boundary calls.
It’s definitely not bulletproof. Breaking it is currently as easy as using apply to dynamically invoke the function. This can be detected though, and I plan to address it, but even then you can work around by constructing the module name dynamically.
All that said, boundary will make you work harder to introduce unwanted dependencies into your codebase.
It would certainly help stop “accidental” usage where someone who doesn’t understand the @moduledoc false idiom calls a function directly instead of through private api.
Thanks all for the information and suggestion. For now, I think I will just apply @moduledoc false and @doc false as an indicator that a module or function is private and should not be called directly.
Other solution like defmodulep, boundary seems a lot heavy weight and add more load to developers. I like the idea but apply to my real project seems not feasible.
unitembdded is the most promising but I don’t like the idea of writing module code and tests together.
So I would go with the convention approach and developer should be responsible when use a module/function
Add 
