I would argue that you are sticking to a technique that doesn’t make much sense for Elm, just because other languages use it.
TDD was formulated around the idea that your tests should test everything at almost every level of writing code, both unit and integration tests, and hence reduce the amount of bugs.
Although it sounds sexy it is hard work, a lot of before-hand thinking making sure that you can move trough pastures of green check marks. But if you take a step back, I believe that valid question is how much TDD is worth in Elm? I would argue that testing everything doesn’t make sense in this ecosystem, and it is not worth the effort, i.e. you are not getting you bang for a buck.
Having said that, you still need to test stuff, especially when you are developing parsers, and such data wranglers, you would like to make sure that they work against squad of test cases.
But does it make sense to hide types needed to test then? Especially if you are developing an application, hence exposing some gory details of your package won’t hurt anybody, hence there are nobody using that module except application developers i.e. you.
So, my two cents are:
Relax, compiler does much of the work, and you write a lot to satisfy that guy, there is no need of inventing new hoops that you need to jump trough, just so you can’t see implementation details of your own module. Hence expose what ever you want to test, it might not be sexy, but at the end of the day, working code is much nicer than theoretically perfect module structure. I have wrote hundreds of thousands of lines of Elm, deleted many many thousands of those lines, because of unnecessary bureaucracy that I invented for my self, because that is what I would do in [obj :C]
Keep it simple <3