Elixir itself and many libraries do that with @moduledoc false and public functions. Yes someone can still call those functions, but they’re excluded from many places like docs, autocomplete, ….
LostKobrakai
2
trisolaran
Exactly, and tight coupling is a design smell 
so when I find myself in this situation, if I can, I try to uncouple instead of testing implementation details.
I agree, to me this isn’t really about public vs. private and not even about Elixir. It’s about desgin of code and tests. When I see “private” my brain reads “implementation details”. All I’m saying is taht I really, really try to avoid testing implementation details if possible.
0
tcoopman
I’m going to drop this talk about coupling and cohesion: https://www.youtube.com/watch?v=3gib0hKYjB0
A great talk in my opinion.
I’d like my implementation details to also be correct 
0
trisolaran
ha! If your implementation details are flawed and nobody from the outside can notice anything, it means that the flaw doesn’t matter, does it? I’m lazy, in that case I say: “who cares”
0
cmo
mindok
The poor guy who comes after you that has to maintain the duct tape and fencing wire implementation
End users aren’t the only users of the code. As @dimitarvp notes - human readability and comprehensibility is a primary concern for sustainable software, and that often involves demonstrating intermediate results (that aren’t of concern to an end user) are correct.
2
trisolaran
My God! This is what you got from what I wrote so far? Ok, I’ll summarize:
- break down your codebase into components/module/classes with clear interfaces and intended behavior
- test the behavior of these components via their interfaces/public APIs
- refactor implementation details until you have code that you like
- if you find yourself wanting to test implementation details of a component/module/class, revisit your design. Maybe the component is trying to do too much, and you can break it down further. Maybe you forgot an aspect of the behavior of the component, which you can now distill into a test
The correctness you should care about is defined by the behavior of your module. If it’s not visible in the behavior then it’s an implementation detail. Don’t couple your tests to these details: you’ll end up with code that is hard to change. Behavior of a module ideally shouldn’t change, implementation details should be able to change: that’s refactoring. The duct tape arises often because people couple things too tightly into a mess which nobody wants to unravel. Testing only behavior and not internal details reduces coupling, and helps make refactoring easier.
So… no mention of “end-user” in the above. I hope it’s clearer now 
P.S: I think that maybe the above seems so obvious to me because I practice TDD whenever I can. I write tests before writing the implemetation, so obviously there are no or very little implementation details I can couple my test to. I imagine (and recall from years ago) that without TDD, keeping your tests separate from the implementation must be harder.
3
mindok
I was being a bit flippant in response to a single post, but thanks for the clarification, and it’s a good end state to head towards.
This is also an excellent thread to challenge and refine our own practices, so thanks to everyone for that.
I am with @ityonemo on other reasons to test, and at times, yes, I absolutely want harnesses around parts of an implementation detail:
Development of non-trivial algorithms often needs check-points, clarification and verification at a lower level than you would want to expose through public/module interfaces.
Hence “no absolute rules” 
.
2
trisolaran
zachallaun
When I’m writing anything remotely interesting, I tend to spend a lot more time “under the hood” than I do working on external API. While I agree in principle that the external API is what matters, in practice, developing new features and only testing them through the external interface is dramatically slower than just testing those things directly. That’s exacerbated by the fact that external API is often messier/stateful compared to a functional core that no one may ever interact with directly.
I suppose that once you’re done, you could delete all those tests that you wrote while building the new thing and trust that the details are sufficiently tested through the external API, but that would seem a bit wasteful.
2