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.
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.
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.
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.
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?
QA Wolf first tries to target elements with test attributes like
For example, if you click on a button with the following HTML:
QA Wolf will create test code targeting the CSS selector
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
submit before timing out, the test fails.
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
As a last resort, QA Wolf will target an element by its XPath.
A best practice in testing is to use test attributes like
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
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.