Refactoring is the process of reorganizing code without altering its functionality. How to ensure that the code behavior doesn’t change after refactoring? Test the code. Tests ensure that our system responds as anticipated under specific circumstances. But what if we have untested code? How to change untested code without breaking it? Let’s discuss the same.
Also Read: Legacy Code Refactoring Techniques and Best Practices
Where should I start with untested code?
Refactoring or changing the untested code is pretty similar to the chicken-egg problem. How? Whenever you ask how to change untested code without breaking it you are advised to
- Write tests so you have some code validation and you do not break the code.
- However, the code is so disorganized that you must restructure it before writing tests.
It wasn’t written by you, either. Your task today is to change that, though. And you must do it without altering the system functionalities.
The first case would be to write tests. So that you can validate your code while refactoring. You can use unit testing for the same.
We want to change the untested code but we have no idea how the code works.
Running the code in various scenarios and observing how it behaves can help you understand what the code does. We can speed up the testing process by capturing these scenarios in automated tests so that we can run them repeatedly rather than by hand. That means:
- Run the software
- Compare its functionalities against different tests
- Refactor to the optimal way
What is Unit testing?
The practice of maintaining the functionality and quality of code through tests is known as unit testing. In addition to developing code, developers also write test code.
The test code is primarily concerned with determining whether a component of the software operates as anticipated and highlighting any defects that may be present.
With the help of this method, you can approach untested code quickly and with minimal risk of disrupting any system or feature. Any code that encapsulates business logic and domain objects is a good fit for unit testing.
You may also choose E2E tests. End-to-end (E2E) tests simulate how an end user would interact with your application. They usually require that your application be built and tested in a production-like environment.
An alternative approach
An alternative or a more detailed way to change untested code will be to begin testing from the outside of the code and work your way in.
1. Start from outside to change untested code
You are usually not very knowledgeable about untested code. The easiest place to start when writing tests is at the highest or outer level.
To ensure that you capture the current behavior of the code, the important concept is to swiftly construct a safety net as a validation method. Using approval testing is the most effective method for doing it.
Approval testing is quicker than developing unit tests and, it supports the statement that you do not comprehend all the code right now. It acts as a test suite to help you refactor the untested code.
Your approval testing is done in 4 parts:
- You set up everything required to conduct the test during the Arrange stage.
- An Act step is where the code is executed.
- A printer phase where you create a string output from the code’s results
- Comparing the current output against the previous output is known as an assertion step.
2. Work your way in to approach untested code
You can begin to change untested code once you have enough outer cases to handle the codebase. The easiest and quickest way to do this is to break it up into small manageable pieces. Redesign the important sections of code that are covered by tests.
Tests don’t obstruct refactoring, but they do confirm that the overall behavior continues to function as predicted. Even better, you can create an entirely new optimal function to replace some code and get the same outcome.
Alongside this, you can create tests for code units. These tests will help you remember how these smaller components work, making it simpler to work with the code and maybe reuse it in the future.
The best method to start when you’re short on time is to use Approval Tests to capture the behavior of existing code.
Select a rough section of code and work on it. It makes refactoring untested code easier and safe, saving you time from having to troubleshoot problems as they arise.
The best approach is to start small
We know that testing untested code is a challenging task but starting with small steps will help you throughout the way:
- It lessens the possibility of breaking the code. Your brain can only handle a certain level of complexity. So instead of approaching the entire code. Start small and scale big.
- Large modifications make it more difficult for you to simply reset and continue if you messed up the current phase. It’s easier to reverse a small task than a big one.
- Refactor your untested code considering the tests you write. You must create tests for your code now or in the future to validate changes against a scenario. Use this moment as the best opportunity to act and do it now.
If all of this seems difficult, hire us
It is needless to mention that changing untested code without breaking it can be time-consuming and nerve-wracking and isn’t everyone’s cup of tea. If you want expert guidance and help to refactor your untested legacy code then get in touch with us at Wolf-Tech.
Conclusion
Refactoring untested code may be difficult. You must be afraid of breaking the code but the right way is to enter and work on it. Pick a small piece of code, write a test and run the application against that test then change untested code optimally.
