Some thoughs about "Nicolas Carlo: Comparing 2 approaches of refactoring untested code"
The mentioned measures "Write high level tests first" and "Start refactoring immediatly" actually fall short in legacy-code refactoring.
Before thinking about changing code, it is imperative to gain an understanding of the software's function.
A good source for a better understanding can of course be existing requirements.
But practice often shows that with "grown" code, the current requirements were no longer included with the code changes.
To achieve a better understanding of legacy code, techniques such as those described in "The legacy code programmer's toolbox" by Jonathan Boccara can be used. (including "10 techniques to understand legacy code").
After analysing the code, an attempt can be made to make minor changes to the existing code.
As you point out in the article, this can be approached in the context of TDD with fakes, stubs and spys.
In my opinion, however, a more systematic approach would be to make the first changes using the Mikado Method (Mikado Method, by Ellnestam & Brolund).
This way, a target picture can be formulated and the way to get there can be well documented.
Incidentally, this method does not contradict the TDD method, but supports it in a very good way.
Some characteristics of the methods mentioned above
Write high level tests first
- Flaky tests (as described in the article) are in my opinion completely worthless
because every time the tests fail, it has to be investigated if the malfunction is caused by the test or by the code
- Complicated to create because of the dependencies.
- Mostly complete parts of the application or the library are needed to create the test.
- Dependencies to the outside world (database, UI etc) are required.
These dependencies generally have "state". This makes writing tests even more time-consuming.
- Deploying the environment is made easier by Docker, but makes the tests even more time-consuming to maintain.
Different states of the database have to be prepared before the tests.
Storing the test scenarios in another repository
Slows down test processes.
- Due to incomplete requirements, it is difficult to guarantee the completeness of the tests.
Direct refactoring
- Carries the risk of introducing errors.
- Refactoring of individual classes is too little as a measure
Possible structural problems can be overlooked by focusing on individual classes.
- The creation of fakes, stubs and spies in large projects poses problems in terms of maintenance but also the motivation of the developers.
Some thoughs about "Nicolas Carlo: Comparing 2 approaches of refactoring untested code"
The mentioned measures "Write high level tests first" and "Start refactoring immediatly" actually fall short in legacy-code refactoring.
Before thinking about changing code, it is imperative to gain an understanding of the software's function.
A good source for a better understanding can of course be existing requirements.
But practice often shows that with "grown" code, the current requirements were no longer included with the code changes.
To achieve a better understanding of legacy code, techniques such as those described in "The legacy code programmer's toolbox" by Jonathan Boccara can be used. (including "10 techniques to understand legacy code").
After analysing the code, an attempt can be made to make minor changes to the existing code.
As you point out in the article, this can be approached in the context of TDD with fakes, stubs and spys.
In my opinion, however, a more systematic approach would be to make the first changes using the Mikado Method (Mikado Method, by Ellnestam & Brolund).
This way, a target picture can be formulated and the way to get there can be well documented.
Incidentally, this method does not contradict the TDD method, but supports it in a very good way.
Some characteristics of the methods mentioned above
Write high level tests first
- Flaky tests (as described in the article) are in my opinion completely worthless
because every time the tests fail, it has to be investigated if the malfunction is caused by the test or by the code
- Complicated to create because of the dependencies.
- Mostly complete parts of the application or the library are needed to create the test.
- Dependencies to the outside world (database, UI etc) are required.
These dependencies generally have "state". This makes writing tests even more time-consuming.
- Deploying the environment is made easier by Docker, but makes the tests even more time-consuming to maintain.
Different states of the database have to be prepared before the tests.
Storing the test scenarios in another repository
Slows down test processes.
- Due to incomplete requirements, it is difficult to guarantee the completeness of the tests.
Direct refactoring
- Carries the risk of introducing errors.
- Refactoring of individual classes is too little as a measure
Possible structural problems can be overlooked by focusing on individual classes.
- The creation of fakes, stubs and spies in large projects poses problems in terms of maintenance but also the motivation of the developers.