AI-Powered E2E UI Testing: Faster Creation, Easier Maintenance

Hello, everyone. My name is Daniel Ostrovsky, and today we are going to explore AI-powered end-to-end testing. But before we dive in, go ahead and scan this barcode to follow me on Twitter, Medium, and YouTube. You can find me as nanduh81. Thank you.

And let's continue. So first of all, a little bit about myself. I'm a full-cycle developer expert. I have more than 25 years of experience. I'm a public speaker, public writer on multiple languages. I'm an open-source contributor, technical mentor, and again, scan the barcode and follow me.

So let's jump right into the challenges that we face in when we're trying to test UI with AI. Okay, now, unlike unit tests, where we can send the source code directly into a LLM, which makes it easy for the model to predict how to test should look like, UI testing is different. So for unit tests, tools like, you know, Copilot and others can generate a test in seconds because they have the full context, source code, and logic that needs to be tested. And in most cases, it works perfectly because the code and context are clear. But when it comes to UI testing, there is a huge layer of obstructions between the source code and what we're actually testing, the rendered UI.

So here's the path. We start our code with actually includes HTML, CSS, and TypeScript, right, that get transpiled into the JavaScript. Then it bundles with tools like Webpack, Write and others. It just make all the transpolation, you know, the bundle and other things. Okay. Unifications and everything. And then it goes to renders engines like React and Angular that takes over the browser. OK, then finally, everything will be rendered by browser. Now only at that point, we do get the actual visual elements we need to test. OK. So where's the source code and what actually we need to test? It's a huge difference. So if we're talking about the standard e-commerce website or blog or something similar, AI has a lot of existing knowledge to get from because it's trained on similar publicly available data. So when we send data to an LLM, 80% of the time, it can generate tests effectively because, you know, AI is already familiar with the existing patterns. OK, but what if you are working on something niche, like an internal application behind a strict authorization or a tool that only works on premise? The LLM doesn't have access to these systems, and therefore, it doesn't understand the specific flows, user interactions, and functionality.

It's not like e-commerce where adding an item to the cart and checking out is predictable. What if you're testing some kind of configuration tool for managing hundreds of gas stations in the middle of the ocean? So AI won't know how to handle it without our guidance. So that's where we need to help AI to help us.

And for that, we follow two key best practices. First, use meaningful data test IDs. In our case, we use data CY since we're working with Cypress. But the principle remains the same. Elements like buttons and input fields should have clear descriptive names, such as next button, username input, and so on. This helps the AI understand the purpose of each actionable item. Second, we rely on the page objects model pattern. While the AI will generate this page for us, so we don't need to create it and it'll show how we're doing it, it's crucial to maintain and manage them. This approach makes our tests cleaner and more modular.

Lastly, we will need tools. One of them is an in-browser extension called end-to-end test helper. You can scan this barcode again, barcode always and check it out. Contribute, please, or just explore the documentation. And please take a look and consider a contribution. I really would love to have more hands in the room. For the third tool, we use an IDE extension called continue. It's a fantastic extension, by the way, similar to tools like Copilot and others that help you manage and work with your code directly in UID. It offers powerful auto-completion and many other cool features that, by the way, Copilot doesn't have. It's open source, so definitely check it out. It's a great tool to have in your toolbox. Great, all right.

So let's move to the demo, to the real demo. Give me a second. Here we go. So, this is the application that we will create the tests for. This is the Pokemon application. We have the Pokemon list ability to filter by name or filter by type.

We also have the navigation into the more details page or Pokemon details page, previous, next, and we can go back to the list page. So this is the application that we're going to run the test on. This is our test and this is our code.

Here we have, first of all, the test case. They are well written, defined test case that basically should be done by QA somewhere before actual development begins. It's a human language, as you can see, natural language. Our test case. Okay? Scenario. Test scenario that needs to be tested.

I also have created the Pokemon list page object. This one I have created by myself because we don't have enough time to create everything during the demo. But the details page object I will create with you together, and I will show how we create it, and what we're doing with that. And this is the empty file for our test that we will generate. Okay? So let's start with the Pokemon details page. We're going to our Pokemon details page. Okay? This is Pokemon details.

As I said, we're going to use our extension. By the way, in this extension, there are settings. You can select what type of object, llama, whatever you're working with. AI LLM. Prompts you can manage your system messages. Okay? And also, just save them for use. Okay? Do not enter each time. Same. We have user prompts. Also, you can create if you need. And here, basically, the main view. Okay? So first of all, we can scan. Okay? All elements. We can see that this one has 105 elements.

We also can see for the debugging what the elements are. Page object name. Pokemon details page. System message. The one that already stored, predefined. User prompt not relevant. And let's send the request. Let's wait a little bit. And now. Okay. Okay. Sorry for that.

Here, we have the page object. Let's just copy. We also can just save it to the file. Let's go back over here. And here we go. We need just to make it exportable. Okay. So, now we have our page object for the Pokemon details page. And we will use the extension. Okay? Continue extension. And all we will do is just ask. It's predefined comment. You can create on your own. End to end test. Create the end to end test. And pass the context. The context I will pass all the open files. Or I can go file one by one.

Okay? But I don't want to spend the time. So I will go with all open files that I have right now. That's exactly what I need. I need all the page objects that we have. I need the test case itself. That's what I'm going to send to EI with the equation, with the predefined prompt.

Again, unfortunately, we don't have enough time to go over. But there is some system message that says, Hey, you are the expert in end to end testing. And some other additional information. And some kind of definition that EI, generally, we have to be aware of. Okay. Enter. And here we go. This is our test. Let's copy. Let's paste it here. This is the only one issue that we always have.

Okay, that's it. Let's go. Here the test runs and it works. Okay. Let's go back to the slide. And that's basically it, I believe. Thank you very much. Find me. Follow me. Thank you very much. Have a wonderful day.