The big risk about refactoring legacy code is most of the time there is no unit tests on legacy code, that is why it is called legacy code, right? Before refactoring, you need add unit tests first, but that needs you fully understand the legacy code, which is hard, sometimes it is impossible. And don't laugh, it is reality. And during you adding unit tests, you also need refactoring since legacy code is not testable… feel like you dig a big hole for yourself, and your boss won’t appreciate. I have to say, I pretty much watched all your talks about unit testing and your book, learn a lot from you. Thank you.
Yes, it is hard. But not impossible! I feel like most of it comes down to using good tools. Here's the workflow I learned: Let's say we're refactoring a class. 1) The class was not designed to be testable, so it most likely has external dependencies. 2) Create seams around the dependencies with AUTOMATED refactoring operations. 3) Create an internal class Testable{ClassName}, inside your test suite, that inherits from the class under test. 4) The testable class will override default behavior on the seams, and allow for dependency injection. 5) For now, instantiate objects of the testable class instead of the original. 6) Inject/mock dependencies as needed, a good framework is always welcome here. 7) Write unit tests (steps 1-6 were setup, haha); try to start testing the execution through the shortest branches first. 8) While writing unit tests, use code coverage to verify that your understanding of the code execution is correct. 8a) during code coverage verification, it might be beneficial to execute one test at a time. 9) When code is fully tested, you can start refactoring. 9a) Note: full coverage does not mean fully tested; when in doubt, it's better to over-test than to under-test.
Refactoring legacy code is dangerous. But it’s more dangerous to not write those tests. In the beginning you’re slow and can’t easily add features/fix bugs very quickly. But when your tests start catching bugs other developers introduce, and tests get easier and easier. You’ll find your team resisting you less and less and eventually relying more n your tests to ensure functioning
You don't actually need to understand the legacy code to test it. You can use acceptance/approval testing, that captures what the code is already doing, and making sure you have 100% coverage.
I have worked at two companies where their main app failed because they got the unit tests so wrong and that took everything else down with them. It is a great tool, but it is often wielded in the hands of people who think if some is good then more is better.
The big risk about refactoring legacy code is most of the time there is no unit tests on legacy code, that is why it is called legacy code, right? Before refactoring, you need add unit tests first, but that needs you fully understand the legacy code, which is hard, sometimes it is impossible. And don't laugh, it is reality. And during you adding unit tests, you also need refactoring since legacy code is not testable… feel like you dig a big hole for yourself, and your boss won’t appreciate. I have to say, I pretty much watched all your talks about unit testing and your book, learn a lot from you. Thank you.
Yes, it is hard. But not impossible! I feel like most of it comes down to using good tools. Here's the workflow I learned:
Let's say we're refactoring a class.
1) The class was not designed to be testable, so it most likely has external dependencies.
2) Create seams around the dependencies with AUTOMATED refactoring operations.
3) Create an internal class Testable{ClassName}, inside your test suite, that inherits from the class under test.
4) The testable class will override default behavior on the seams, and allow for dependency injection.
5) For now, instantiate objects of the testable class instead of the original.
6) Inject/mock dependencies as needed, a good framework is always welcome here.
7) Write unit tests (steps 1-6 were setup, haha); try to start testing the execution through the shortest branches first.
8) While writing unit tests, use code coverage to verify that your understanding of the code execution is correct.
8a) during code coverage verification, it might be beneficial to execute one test at a time.
9) When code is fully tested, you can start refactoring.
9a) Note: full coverage does not mean fully tested; when in doubt, it's better to over-test than to under-test.
Refactoring legacy code is dangerous. But it’s more dangerous to not write those tests.
In the beginning you’re slow and can’t easily add features/fix bugs very quickly.
But when your tests start catching bugs other developers introduce, and tests get easier and easier.
You’ll find your team resisting you less and less and eventually relying more n your tests to ensure functioning
You don't actually need to understand the legacy code to test it. You can use acceptance/approval testing, that captures what the code is already doing, and making sure you have 100% coverage.
I have worked at two companies where their main app failed because they got the unit tests so wrong and that took everything else down with them. It is a great tool, but it is often wielded in the hands of people who think if some is good then more is better.