Some test automation tools claim to import tests from other frameworks into their platform. Whether importing Selenium, Appium, TestProject, Cypress, Playwright, Puppeteer, or any other scripted tests, there are significant limitations on what will actually work. And even in rare instances where the imported tests work, they often carry forward the same flakiness and maintenance issues they were trying to leave behind.
In this post, we will review why importing scripted tests (with a focus on Selenium) rarely works in practice, and even then, it consumes more time and resources than it’s worth.
Before you consider importing Selenium
Selenium has been around for nearly 20 years, so it’s no wonder people want to leverage their existing scripts if they move to another test automation platform. However, you must first ask a couple of critical questions:
- Do all the Selenium tests serve a useful purpose? The tests may have been created years ago for very valid reasons. But the application has stabilized over time, and you no longer capture any regressions with these tests. Yet, you still run them out of habit. Migrating from one system to another is a perfect time to evaluate whether the tests are valid. Ask yourself if they would catch a regression if they occurred.
- Is the maintenance of the tests a burden? If the answer is yes, you probably don’t want to move the burden to another platform. In most cases, migrating Selenium tests means you won’t take advantage of any advancements in the new automation platform. Your tests will continue to use single selectors to locate elements, requiring constant upkeep.
- Are they testing the right things? Risk-based testing suggests that you focus on the areas of your application that pose the most significant and most likely risks. Your application has likely matured since you wrote those scripts, meaning that application areas that once posed a bug risk are now stable and perhaps need a different strategy.
In evaluating these questions, you’ll likely conclude that you don’t need all those tests to cover the application adequately.
But what about the ones you do need? Keep reading.
Why importing Selenium is hard
Individuals wrote Selenium tests. Some may be very clean and efficient tests, and some may not. Any tool that attempts to convert that code into a no/low-code solution will likely make some mistakes.
Users write Selenium tests in Java, C#, Python, JavaScript, and Ruby. Does the import tool work on the language of your Selenium tests? If not, they likely won’t import.
Your Selenium tests may drive browser actions that aren’t supported by the low-code test automation tool. Alternatively, you may have older Selenium scripts that use Selenium actions that have been changed in newer versions of Selenium. Does the import tool support all versions?
It’s also highly likely your Selenium tests include custom code that can’t be converted to a no/low code step. Customizations appear in 95% of TestProject tests, making them poor candidates for import.
Selenium tests contain assertions that validate that the outputs of a test match expectations. For instance, if you have an eCommerce app, you might want to validate that the price of an item in the catalog equals the price in the shopping cart.
Selenium uses single-element selectors to find objects in a UI. If the underlying selector changes, the test can’t find the element and likely has a false positive result. It’s one of the reasons many QA teams are switching to modern tools that use AI to identify objects in the application. Without manual intervention, most tools can’t convert those single selectors into AI-powered locators. Thus, importing Selenium scripts often inherits the flakiness you are trying to avoid.
What some vendor tools claim
Some vendor tools (names withheld to avoid shaming the guilty) claim to import Selenium, Appium, TestProject, or other scripts. They may even claim that you can import them in bulk—just run some commands, and everything will work like magic.
What would this mean in practice?
- You can only import tests written in a supported language. So, if you wrote your tests in Python and the import tool only supports Java, you are out of luck.
- Importing would only keep the steps that have an equivalent low code step. Thus, importers skip custom-coded steps, and you must recreate them in the new test, either as a low-code step or a coded step.
- You need to recreate assertions. Users would manually add low-code steps to assert/validate each critical part of the test. Without these assertions/validations, they wouldn’t serve a useful purpose.
- Users would need to add data to the imported tests—especially if you plan to parameterize the variables and use data-driven testing.
- Single selectors will likely carry their flakiness into the new tool. If you still have the same flakiness issues at the conclusion of this significant effort to import and modify your scripted tests, have you really improved anything?
Testim doesn’t import Selenium scripts
No, Testim doesn’t import scripts from other tools like Selenium, Appium, or TestProject, and we think that’s okay. Importing takes a lot of time and inherits the same maintenance issues in Selenium. And blanket import jobs often ignore testing strategies that focus tests on the parts of your application that are most risky—in terms of likely bugs and the impact of the defects.
Testim instead focuses on ease of authoring and AI-powered stability. Users can author stable tests fast, often 95% faster than scripting. We argue that you can author a new test as quickly as you can import and modify a Selenium test in another tool. And with Testim, you get self-improving, self-healing, AI-powered stability.
