Although we like to think that we always design stable classes with single responsibilities that are closed for modification but open for extension (see Martin [2014] for more about the Open Closed Principle), in practice, that does not always happen. Your production code will change, and that will force your tests to change as well.
Therefore, your task when implementing test code is to ensure that changing it will not be too painful. I do not think it is possible to make it completely painless, but you can reduce the number of points that will require changes. For example, if you see the same snippet of code in 10 different test methods, consider extracting it. If a change happens and you are forced to change that code snippet, you now only have to change it in 1 place rather than 10.
Your tests are coupled to the production code in one way or another. That is a fact. The more your tests know about how the production code works, the harder it is to change them. As we discussed a clear disadvantage of using mocks is the significant coupling with the production code. Determining how much your tests need to know about the production code to test it properly is a significant challenge.
Leave a Reply