In trying to relate the relationship I see between testing and refactoring, the expression "It takes two to tango" keeps coming to mind. If the process of keeping software flexible and reliable under an onslaught of new features is a complex dance, then testing and refactoring are the key dance partners. They rely on each other in a complex and iterative way. You need tests to refactor effectively and you need to refactor to test affectively.
Our team learned the hard way that applying semi-rigorous TDD overtime without giving sufficient attention to coupling (and SOLID principles in general) can lead you down a path towards test-suite maintenance hell. We failed to control the size of monolithic components and allowed ourselves to hack in more functionality. We became burdened by brittle tests (chalk full of mocks) and complex test utilities. At some point you start to lose the benefits of TDD, and even worse you start to lose faith in TDD (unit testing in general) from developers and management.
We were fortunate enough to be given time for some major technical debt pay downs. After some major modularization, levelization, and refactoring to adhere to good design principles, clean and clear testing paths re-emerged for code that was previously seen as too difficult to test. Disciplined testing of changes in that code could again be fast and reliable.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
In trying to relate the relationship I see between testing and refactoring, the expression "It takes two to tango" keeps coming to mind. If the process of keeping software flexible and reliable under an onslaught of new features is a complex dance, then testing and refactoring are the key dance partners. They rely on each other in a complex and iterative way. You need tests to refactor effectively and you need to refactor to test affectively.
Our team learned the hard way that applying semi-rigorous TDD overtime without giving sufficient attention to coupling (and SOLID principles in general) can lead you down a path towards test-suite maintenance hell. We failed to control the size of monolithic components and allowed ourselves to hack in more functionality. We became burdened by brittle tests (chalk full of mocks) and complex test utilities. At some point you start to lose the benefits of TDD, and even worse you start to lose faith in TDD (unit testing in general) from developers and management.
We were fortunate enough to be given time for some major technical debt pay downs. After some major modularization, levelization, and refactoring to adhere to good design principles, clean and clear testing paths re-emerged for code that was previously seen as too difficult to test. Disciplined testing of changes in that code could again be fast and reliable.