Bring old test automation project back to life
Starting a new project can put you in a situation where you have to decide: whether to begin again or try to fix you have.
If all the tests work and wrote in a simple, SOLID, and understandable manner, you are lucky. Close this article.
But if you get a disordered confusing code written two years ago by a person who doesn’t work here now, deadline is coming , so the dilemma is difficult.
I’ll omit speculation whether to start a new project. It depends on the particular situation.
In a short while, I fixed several test automation projects with the outdated tests and messy code. I wasted a days solving the problems supplied by myself because started in a bad way. I would like to share the conclusions I made for myself, how to refactor old tests quickly.
My main idea: Start refactoring from tests to understand the reason, why code wrote in this way. Changes provided without knowing the full context, can lead to significant and unexpected changes on a test run process. Then you must make an extra effort to correct this behaviour.
1. Define a baseline
This step applies in a situation when the old test and page objects are still relevant in some ways and the application under tests is not changed so much. In this case, we need to retrieve as many tests as we can in a short time.
Use some quick win steps:
— recover or create test users
— update hosts, connections strings, test configuration
— update test data — fix xpath/css locators .
This step is necessary, but don’t spend so much time on it. We will be back to the invalid tests later.
I put this step first because:
— Poorly written tests that work better than nothing. Refactoring will take some time, and test execution can be required at any time.
— Working set of tests this is your reference point to verify does refactoring break something
2. Fix Structure of the tests
Go throw all test methods and underhand their purpose. Compare with the actual status of a product.
Define missed test cases and clean up irrelevant. Maybe some tests had similar preparation steps and can be merged into the single one. Maybe some tests check situations unlikely to happen or have very little severity compared to the time spent to test them.
Check that packages group test classes related to the tested application part. Packages and classes names cleared indicate tested functionality.
Verify that test method names indicate functionality to tested and expected result. It may contain word ‘should’, for example: userShouldSeeNavigationButtonsAfterAuthorization.
3. Add narrative to the tests
Tests methods should tell a story. Story understandable by anyone.
Put interactions with the application and assertions inside well-named methods inside page objects. Voilà, the tests written in natural language:
Rename the methods inside the page objects and create new ones if needed. All for readability.
Also, reduce the amount of repeated code inside beforeClass/beforeTest methods. Make a separated basic test class to keep variables and page objects used in most tests and inherit all tests from this class.
4. Optimize Page Objects
After refactoring on a test classes level, page objects already contain all necessary methods. It remains to fill a new one with code and refactor the old one.
Remember to run tests once in a while to make sure that code changes don’t break anything.
5. Clean up supported classes
Now you have comprehensive and functioning tests and succinct page objects. Remain classes are usually some sort of utilities, clients, and configurations.
Typically, after simplifying tests and page objects, you may find, that some supported classes are no longer needed or find a bunch of unused parameters in configuration classes.
Get the rest of your classes in order, and you’re done. These are small thoughts on the topic after tidying up a few test automation projects.
Share your experiences with legacy projects in the comments.