Menu
In the course of a TDD session, suppose I write a failing test, and then make it pass. I refactor by extracting code out of the original Unit, using refactorings such as Extract Class and Move Method. Now further suppose that my original test no longer covers the extracted code because the original code now mocks out its dependencies, as is correct for a Unit test.
Is it proper to go back and retrofit tests onto the extracted code? Or did I make a mistake in how I ended up with untested code during a refactoring? It feels like as my codebase is scaling, and I have to refactor, I'm retrofitting a lot of tests onto refactored code. This feels really awkward. Am I refactoring wrong?
827
The best time to consider refactoring is before adding any updates or new features to existing code. Going back and cleaning up the current code before adding in new programming will not only improve the quality of the product itself, it will make it easier for future developers to build on the original code.
Create a maintainable codebase The next step required in the TDD process is refactoring, which stands for the optimization of existing code and has the single objective of making it simpler to introduce. Developers can refactor a tiny feature or improvement's code to meet standards if it passes the initial tests.
The ultimate goal is refactoring – a fundamental step in TDD. By continuously refactoring the code through the failed tests during development, it will allow for quick refactoring in the future. With TDD, the tests help you run the development of the code (as well as the design of the software).
Test-driven development (TDD) is an approach to software development where you write tests first, then use those tests to drive the design and development of your software application.
Now further suppose that my original test no longer covers the extracted code because the original code now mocks out its dependencies, as is correct for a Unit test.
Mocking dependencies is frequently a good thing to do, but not always, and I wouldn't say it's "correct for a unit test" to mock all dependencies.
In the refactoring step of TDD, you should be changing things in the production code that don't affect the passing of the tests. And you shouldn't be changing the tests at the same time.
You might want to later modify your tests so that the extracted code is tested independently of the original code and is mocked in the original tests.
195
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
