QA Wolf logo

QA Wolf



Convert Actions to Code

In this guide, we explore how QA Wolf converts your actions to code.

You'll learn how to toggle auto code creation on and off. You'll also learn how QA Wolf chooses selectors and about best practices for front end code.

Toggle Code Creation

As you use your site, QA Wolf converts your actions to Playwright test code. You can turn auto code creation on or off depending on your needs.

In the top right corner of the test editor, there is a toggle in the "Code" tab. When this toggle is set to on, it has a magic wand icon. This means that when you use your site, your actions will be converted to test code.

Create code toggle

When the create code toggle is set to on, you'll notice that the comment below is added to your test code:

// 🐺 QA Wolf will create code here

This comment tells QA Wolf where to insert new test code. If you want to insert test code in a different place (like in the middle of your test), move this comment where you want the new test code to go.

If you delete the // 🐺 QA Wolf will create code here comment, you'll notice that the create code toggle is set to off. Turn the toggle on again to add this comment back to your code.

Clicking on the toggle also turns off auto code generation. When code creation is turned off, the toggle has a pause icon. Now when you use your site, your actions will not be converted to test code.

Code creation turned off

You can turn code creation on and off as often as you like.

One caveat is that code generation does not work while a test is running. QA Wolf will wait until your test passes or fails before converting additional actions to code.

How QA Wolf Picks Selectors

As you use your site, QA Wolf picks the best selector for each element (like a button or text input) that you interact with. But how exactly does this work?

Target Attributes

QA Wolf first tries to target elements with test attributes like data-cy, data-e2e, data-qa, data-test, or data-testid.

For example, if you click on a button with the following HTML:

<button data-qa="submit">Submit</button>

QA Wolf will create test code targeting the CSS selector [data-qa="submit"]:


When you run your test, Playwright will look for an element where the data-qa attribute is set to submit. If it cannot find an element where data-qa equals submit before timing out, the test fails.

Default Selector Logic

If the element does not have a test attribute like data-qa, QA Wolf falls back to its default selector logic.

In a nutshell, the default selector logic chooses the best available CSS or text selector for the target element. It prefers attributes like id over attributes like href. If there is not a matching selector for the target element alone, QA Wolf will try to find one that includes an ancestor.

The default selector logic checks that the selector does not match a different element. It also does its best to avoid using dynamic class and id attributes.

As a last resort, QA Wolf will target an element by its XPath.

Selector Best Practices

A best practice in testing is to use test attributes like data-qa or data-test in your front end code. These selectors make your tests more robust to changes in your application code.

If possible, you should consider updating your front end code to include test attributes. Don't worry - you don't need to do this all at once. If a test attribute is not included for a test step, QA Wolf will fall back to the default selector logic.

For example, let's say we have a submit button with the following HTML:


To explicity label our element for use in testing, we'll add a data-qa attribute with the value of submit:

<button data-qa="submit">Submit</button>

Now even as the text, CSS classes, and other attributes of our submit button change, the data-qa attribute will always label it as the submit element to use in tests.