I definitely wasn’t suggesting that. Just that in your case it just makes sense to me to separate it. @LostKobrakai sounded my opinions nicely.
But your test is using that method (function) nevertheless, so (again, for me) it just makes sense to make it public. Then again, this is probably the flaw of languages that only have two access modifiers. In Java, for example, I can just define the method package-private and let the test be in the same package, therefore giving access to all methods necessary. Yeah, I can’t believe I just compared Elixir to Java either.
By separating that function into another module, basically you get:
- Separation of concerns
- The ability to call the encrypt function from test, which means you don’t need to jump hoops
- The ability to create a mock of the Encryption module (e.g. via the amazing Mox library) if you don’t actually care about the implementation of the encrypt function
That indeed introduce the cost of indirection and opening possibilities of other modules “accidentally” calling that function. But yeah, most libraries I’ve seen in languages like this usually just define an Internal modules with big warnings that you shouldn’t depend on them, while still actually allowing others to access it. A trade-off that you need to weigh.
I wholeheartedly agree.
This too. It makes sense to test internal implementations, although I can see the test code would definitely change a lot as implementation changes, but not necessarily a thing you need to avoid. Btw, OP wants to use the private function, not test it, I don’t know if that makes a difference 
–
There was also this proposal thread (in which the package private was mentioned):
https://elixirforum.com/t/proposal-docp-for-private-function-documentation-and-doctests/3732
