DHH wrote an article with the title "test induced design damage", not sure if he coined the term.
I think there's a grain of truth there; it is possible, but not necessary, to mangle your architecture to enable testability.
The case that DHH was complaining about is quite interesting in itself; it was an architecture that Weirich suggested (https://www.youtube.com/watch?v=tg5RFeSfBM4) where the framework DB models (in his case Rails) are separated from the Domain Models, to allow you to 1) run your tests of the business logic faster (without spinning up a DB) and 2) decouple your business logic from your choice of framework.
I've felt the need for this factoring in my own code, but actually making it happen is tricky, since you lose a lot of the magic that makes your life easier (but that also couples every level of your architecture to the framework's concepts).
http://blog.cleancoder.com/uncle-bob/2017/03/03/TDD-Harms-Ar...
DHH wrote an article with the title "test induced design damage", not sure if he coined the term.
I think there's a grain of truth there; it is possible, but not necessary, to mangle your architecture to enable testability.
The case that DHH was complaining about is quite interesting in itself; it was an architecture that Weirich suggested (https://www.youtube.com/watch?v=tg5RFeSfBM4) where the framework DB models (in his case Rails) are separated from the Domain Models, to allow you to 1) run your tests of the business logic faster (without spinning up a DB) and 2) decouple your business logic from your choice of framework.
I've felt the need for this factoring in my own code, but actually making it happen is tricky, since you lose a lot of the magic that makes your life easier (but that also couples every level of your architecture to the framework's concepts).