5

How to Refactor a Legacy Test Automation Project

 2 years ago
source link: https://dzone.com/articles/how-to-refactor-legacy-test-automation-project-sav
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

How to Refactor a Legacy Test Automation Project

Bring old test automation projects back to life.

Join the DZone community and get the full member experience.

Join For Free

Starting a new project can put you in a situation where you have to decide whether to begin again or try to fix what you have.

If all the tests work and are written in a simple, SOLID, and understandable manner, you are lucky — you are lucky! 

But if you get a disordered confusing code written two years ago by a person who doesn’t work here now and the deadline is coming, the dilemma is more difficult.

I’ll omit speculation of whether to start a new project. It depends on the particular situation.

In a short while, I fixed several test automation projects with outdated tests and messy code. I wasted days solving the problems because I started in a bad manner. I would like to share the conclusions I made for myself on how to refactor old tests quickly.

My main idea: Start refactoring from tests to understand the reason why code was written in this way. Changes provided without knowing the full context can lead to significant and unexpected changes in 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 test has not changed 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, and test configuration.
  • Update test data — fix xpath/css locators.

This step is necessary, but don’t spend too much time on it. We will be back to the invalid tests later.

I put this step first because:

  • Poorly written tests work better than nothing. Refactoring will take some time, and test execution can be required at any time.
  • A working set of tests is your reference point to verify if refactoring breaks something

2. Fix the Structure of the tests

Go through all test methods and understand their purpose. Compare them with the actual status of a product.

Define missed test cases and clean up irrelevant ones. 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 packaged group test classes are related to the tested part of the application. Packages and class names should 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 a Narrative to the Tests

Test methods should tell a story — a story understandable by anyone.

Put interactions with the application and assertions inside well-named methods inside page objects. Voilà, the tests are written in natural language:

loginPageObject
.openLoginPage
.provideLogin(login)
.providePassword(pass)
.pressLoginButton()
.assertThatUserIsRedirectedToMainPage()
.asserThatUserSeeNaviagationMenu()

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. You still need 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. The remaining 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 just a few thoughts on the topic after tidying up a few test automation projects.

Share your experiences with legacy projects in the comments.

Good luck!

LinkedIn / Github / Medium / Mishustin


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK