> First, as I mentioned, testing is very likely at some point over the evolution of the module to want to either provide input or examine output, intermediate o

> First, as I mentioned, testing is very likely at some point over the evolution of the module to want to either provide input or examine output, intermediate or otherwise, that exists in those types. I have not found this to be true at all. I frequently have very long (300+ line) pure functions that do one thing, and the tests are designed to be oblivious to whatever intermediate representations are used. In fact, I think it's an anti-pattern to pull types out just for testing: tests should not be so granular that they affect how you design functions. For example, a function that takes a JSON string containing multiple objects and returns an SQL string for a batched INSERT operation. I can easily achieve 100% coverage with a table-driven test just checking inputs and outputs. I frequently use function-local types and function-local functions that are reused within the function. Testing has never been a problem. > Second, as the code grows, you want to be able to refactor things freely, and types embedded in functions form a barrier to refactoring because to refactor you'll have to do something to expose that type now to multiple functions. This hasn't been my experience either. When refactoring, I'm usually doing more encapsulation, not less. On a first pass, I write everything to have access to everything else. Only after I have a clearer idea of boundaries do I refactor.