How to write tests for public functions with many complex private functions

lamtrhieu

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.

Hope to hear your thoughts on this matter. Thanks

9 comments

#tdd #learning-elixir #unit-testing

0 1613 9

2020-03-03 14:53:38 UTC

Showing Posts 1 to 9

Show Best Posts
Show All (oldest first)
Show All (newest first)

NobbZ

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.

Post #1

chrismcg

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.

Post #2

NobbZ

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.

Post #3

sasajuric

Author of Elixir In Action

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.

Post #4

hauleth

I have created ExUnitEmbedded for such purposes. It is idea similar to EUnit tests within modules themselves.

Post #5

chrismcg

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.

Post #6

chrismcg

Interesting! I have like that style of testing when I’ve done it in Rust

Post #7

lamtrhieu

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

Post #8

riebeekn

You might also find something like https://github.com/TeachersPayTeachers/publicist or https://github.com/pragdave/private useful if you’re just looking to be able to test your private functions… the above packages allow you to expose private functions as public when under test.

Post #9

— All posts loaded —