A robust, end-to-end test suite greatly simplifies code refactoring. But what to do when such tests were carried out little or they were not performed at all?
What is refactoring?
Generally speaking, refactoring is the reorganization of code without changing its behavior. That is, we prioritize behavior: we need to ensure that when we refactor, we do not change it.
How can this be ensured? The answer is simple: tests. It is the tests that confirm that our system or component behaves as expected under given conditions. With tests in place, the refactoring process is greatly simplified, since we have a means of verification (validation). But well-tested code is the ideal case, and rarely happens in reality. Let's look at a more complex and realistic case.
An animated nightmare called "Legacy-projects"
Consider a scenario from the life of an ordinary (or not so) programmer. Imagine that the manager throws you into a project with legacy code (that is, legacy, not very new, and most often very obfuscated code). No one knows how this code works, the documentation is sorely lacking, and the one that is available was written by an unknown tongue-tied foreigner who wished to remain anonymous ...
So what's now? Don't quit, after all! Although after a couple of hours of digging in the wilds of legacy, this option will seem tempting to you. But give up early! In fact, all that is required of us is to ensure the immutability of behavior. Given the lack of information, this is not a trivial task. Where to start? Write tests. Tests, tests, and more tests.
Step 1. "Smoke" tests
The first type of tests that we will use are the so-called "smoke" tests (English smoke testing). This term is understood as a minimum set of tests for obvious errors. The "smoke" test is usually performed by the programmer himself. It makes no sense to send a program that has not passed this test for deeper testing. Smoke tests are great for demonstrating that the most important part of the system behaves appropriately and predictably. That is, we add smoke tests to our deployment pipeline (create it if you haven't already) in the build verification step. After performing "smoke" tests, we can be sure that we have not violated anything critically. In addition, in addition to this wonderful effect, we gain knowledge: after creating "smoke" tests, we begin to understand the system much better.
Step 2: Unit testing
Our next testing strategy is unit testing. Unit or unit testing is a process in programming that allows you to check the correctness of individual modules of the source code of the program. The idea is to write tests for every non-trivial function or method. This approach is used throughout Java programming. Implementing unit testing is a much more difficult task. This process should be step by step. It's impossible to write unit tests for every component, and it doesn't make much sense to do so, because you're about to refactor anyway. Therefore, you need to make sure that at least the main components behave as expected. So, choose one of the main components and start testing it. Writing unit tests will automatically result in a small refactoring of the legacy code. In addition, you will begin to understand the inner workings of the project much better.
Results
After implementing these strategies, you will not be left with untested code, and the fog of legacy code will become much less dense. Of course, there may be a person in the team who will say that there is no time for testing. Try to convince him that, on the contrary, refusing to test will lead to much (much!) Big time losses in the long run. And, therefore, you should make testing the very first and highest priority task before embarking on arbitrarily serious refactoring. If you are dissuaded from testing - argue, defend your opinion. Otherwise the whole team will fail. If it's impossible to avoid legacy code, test it before refactoring. There is simply no better strategy. Failure to test is a guarantee of future defeat.
GO TO FULL VERSION