"A thought process that can yield interesting design insights is to ask what the system will look like if you design it to facilitate testing. Do you need to separate the user interface from the rest of the code so that you can exercise it independently? Do you need to organize each subsystem so that it minimizes the dependencies on other subsystems? Designing for test tends to result in more formalized class interfaces, which is generally beneficial."
Good unit tests don't happen by accident, however. It's very hard to have good unit tests without having good "units": Portions of code with narrow and well-defined interfaces, which can be tested at those interfaces.
The best way to have such logical units, which then permit excellent tests, which in turn permit rapid feedback cycles while maintaining a mature project, is just to do so directly: Write code with this end in mind.
testing-concept-pure-functions-aid-testability
The problem is – and I want you to think carefully about this next statement – a one-to-one correspondence implies extremely tight coupling.
Think of it! If the structure of the tests follows the structure of the production code, then the tests are inextricably coupled to the production code – and they follow the sinister red picture on the left!
blog-post-test-induced-design-damage