Migrating Test Code with AI: From Frameworks to Languages

One of the questions I always get asked for recommendations on, is moving from one framework to another—or even one language to another. When you’re already invested in some infrastructure, moving to a new one is, let’s say, risky. Not to mention expensive.

It has benefits, of course, otherwise, you wouldn’t be considering it. Most of the time, this requires a hybrid solution where you stay with the old tests and start writing new tests incrementally. I’ve always recommended this safer path because touching lots of moving pieces is risky.

But now, with the new tools for AI in software testing, we have a genie that can change many pieces of code with much more confidence. So the question is, can we really translate our tests and infrastructure using AI?

Potentially, yes. But in practice, there’s a lot we need to do to help the process along.

A First Small Step: UnitTest to Pytest

In our Bigger Better Bookstore^TM, we have a Selenium test for the Login page that uses Python’s UnitTest framework.

Let’s say we want to use Pytest instead. A simple prompt to our AI assistant gets us started:

A few seconds later, I’ve got a Pytest test.

I know, it looks the same, but wait to you see the imports!

Now, this is a very small example, but it already shows why I wouldn’t ask to transform all the tests at once. Since I didn’t give any specific direction, the translation is minimal. It’s already different from how I would write this from scratch. This feeling will not go away (unless you step in and take control of the keyboard).

Taking Control with Fixtures

If I were writing it myself, knowing where I’m going, I’d probably use Pytest fixtures to hold common setup and teardown code. Of course, I can ask our genie to do that too.

And I’d get this, which I can live with for now.

Note that these small steps allow me to review and approve the changes. If I did this across my entire code base at once, I might not notice major impacts, which could be disastrous.

A Bigger Leap: Selenium to Playwright

Okay, next, let’s upgrade!

This is not only quick, it’s pretty safe, as it does very few things.

But let’s run it to make sure… and it works! But not always. I may need to help it a bit, and I always need to review the code changes, to make sure they make sense and no new, strange code has sprung to life. Again, small steps keep me in control.

Go Abstract: Using the Page Object Model

Let’s go back to our Pytest Selenium test. To make it more robust and easier to migrate, we can use the Page Object Model (POM) pattern. Let’s ask our AI padawan to do it for us.

This works, amazingly. It creates a Page Object class and a separate test file.

As almost always, it’s not exactly how I would write it, but I can step in or give more instructions. The important thing is that now the Selenium code is inside the Page Object, and the test itself doesn’t have any Selenium in it. This abstraction makes changes easier and safer—not just for us, but for the genie too.

Now, let’s ask it to translate the new test to Playwright.

And it works, with the provision that I’d still write it a bit differently myself.

But because our whole infrastructure is based on page objects, the translation was easier and safer. At least we have feedback, because we can run the tests and see if we get the same results as before.

The Main Point: Small, Validated Steps

Which gets us back to my main point for any AI in software testing initiative. Technically, you can do mass translation. But in order to have a working, translated infrastructure, you need to take small steps. Change a couple of things, run the tests, and see if they work. Then continue. Exactly as if you would do it yourself.

Now, I want to hear from you. In the comments, tell me about your experience migrating test code, between frameworks or entire languages, and what got lost in translation.