> For the complete documentation index, see [llms.txt](https://docs.dogq.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dogq.io/documentation/scenario-steps.md). # Scenario steps Let's take a look at the different **Steps** available in DogQ. Step represents the single interaction action with the web page. ### Use Macro By selecting this step, you can choose one of the available **Macros** for this Project to execute a specific set of steps. [Learn more](/documentation/macros.md)
*** ### Go to This navigational tool with its two subtypes is used when you need DogQ to either go to a URL or switch between browser tabs. #### Go to URL "Go to URL" step is the beginning of all tests. You specify a URL, e.g., , and upon executing the test, DogQ will load the page and be ready to interact with its elements.
#### Go to Tab There might be cases when user interaction leads to a new browser tab being opened and for DogQ to be able to interact with the elements in a new tab it needs to be navigated there first. To use "Go to Tab" simply insert the number of the tab you want to go to.
Numbering starts from 1 and it's where DogQ operates by default. So, if a new tab has been opened and you want to go there, simply type "2" in the value field.
If you tell DogQ to go to a tab that doesn't yet exist in your test, it will create a new blank tab and give it the next free number. For example, if there is only one tab in your test and you try to go outside of that scope (Go to tab 2, 3, or 6, etc.), the new tab will be assigned number 2. #### Go to Email This subtype tries to find an email in the mailbox created with Email Assign step. An email can be found by either the **body** of the email, the sender's **email address** or the **subject** of the email. If it's found, DogQ navigates there enabling you to interact with the email just like you would with an HTML page.
{% hint style="warning" %} If you have multiple mailboxes in your test, Go to Email will always interact with the one that was created the last before Go to Email was used. {% endhint %} *** ### Check URL This step type asserts that a specific page/URL was opened in the previous step. If the current URL at the moment of the step execution is the same as you provided, this step will pass and fail otherwise.
*** ### Check path This step checks the trailing part of the URL(the part after the domain), e.g. if you're at "dogq.io/login" you can simply use "login" as step value.
The search is performed from the end of the path backwards, in a right-to-left manner, i.e. if the path you're testing consists of more than one directory and you're particularly interested in the middle one, you still need to specify the path up to the very end. For example, if you're at "docs.dogq.io/use-cases/component-testing" and you want to make sure that the "use-cases" part is still there, you need to use "use-cases/component-testing" as step value. "Check path" also supports [RegEx](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_expressions) for paths containing dynamic pieces, e.g. IDs, query strings, etc. In this example we're at "dogq.io/projects/2342" and want to check that a project page with a 4-digit ID has been opened as a result of one of the previous steps.
In this mode "Check path" will try to make a match by a substring regardless of its position in URL, performing the search from the start, in a left-to-right manner, i.e. it checks not just the trailing part of the URL, but the entire URL.
{% hint style="info" %} Remember to enclose your RegEx into "/". Otherwise "Check path" will operate in normal mode, trying to make exact match of the value provided, performing the search right-to-left. {% endhint %} *** ### Click element Use this step to simulate a user clicking on an element. It has multiple subtypes: **Left button**, **Right button**, **Double click**, **Hover**, **By coordinates**, and **Drag and drop**. [**Selectors**](https://docs.dogq.io/documentation/selectors) are used to locate elements and interact with them.
Selectors in DogQ Cheat Sheet **Label (text)** - no special syntax, e.g., `Execute` **CSS selectors** * ID - `#execute-btn` * class - `.btn-green.btn` * attribute - `[href="/login"]` **XPath** * attribute - `//*[@id="execute-btn]` * text - `//*[text()="Execute"]`
#### Left Button Click Left click is naturally the most common one. It clicks on the element specified via selector, just like a user would click on it with their mouse.
#### Right Button Click This variant comes in handy when we need to test JavaScripted custom behavior, e.g., custom context menus, tooltips, etc.
#### Double Click As with Right button click, this subtype can be useful for testing element custom behavior implemented with JS.
#### Hover This subtype simulates a mouse hovering over the specified element.
#### By coordinates With this variant, rather than targeting an element by its selector, you can click a point on a page at the specified coordinates. The input here ix “X, Y” coordinates that are calculated starting from the top left corner of the whole page(not the current viewport).
#### Drag and drop This subtype is used for testing drag-and-drop functionality. To use it: 1. add a **Find element** step and specify a selector for the element you want to **drag** 2. add a **Click element | Drag and drop** step after it and specify a selector for the element where you want to **drop** the dragged element
{% hint style="info" %} **Click element** will try to perform a click on an element, even if it's hidden or disabled. This is done to ensure that users can cover as many cases as possible. {% endhint %} *** ### Find element This step type is used to check that a specific element exists and/or has certain attributes. Oftentimes, It's used to confirm the results of the previous steps.
*** ### No element Use this step to check that a specific element is not present on a page. In terms of selectors, it operates the same way as **Find element** with the difference in the output result. If a specified element is not found, the step will pass and fail otherwise.
*** ### Find input It behaves the same way as **Find element**, with the only difference being that it's looking for an "input" element tag so that you can then use a follow-up step called **Type into** to enter specific text values into input fields.
*** ### Type into Use this step to enter a specific text into the input field found at a previous **Find input** step.
#### Type into Random Value This is one of the alternative modes of **Type into** tool in which DogQ will generate randomized non-duplicate test data based on the RegEx provided. To use this: 1. add Type Into step 2. type "Random//" 3. insert your regular expression between slash signs 4. in the test your RegEx will be substituted with the corresponding random string In this example, we are using a simple RegEx to test the input field validation.
Every time we run this test, DogQ will generate a random 8-character string of letters and digits, which can be seen in the test run report.
#### Simulating pressing Enter key on the keyboard There are cases when certain actions, for example a search on a site or an action confirmation, can only be initiated upon pressing Enter key on the keyboard because there's no dedicated button for it in UI. To simulate pressing Enter, simply add **Type into** step and use **KeyEnter** as its value.
#### Creating a new line Sometimes when entering text into a field you may need to break it into lines and paragraphs. To do so, you can simply include the newline character "**\n**" in your text, This allows you to control where the line breaks occur, effectively creating new lines and separating paragraphs.
In this example we're using two newline characters and here's what the result looks like:
*** ### Find text You can use this step to validate whether a specific piece of text is present and visible on a page. For example, asserting that a particular error message appears. Provide the exact text in the value field. The step will pass if the text is present on the page and will fail otherwise.
If you have multiple pieces of text you would like to find on the page, you can list them in a single Find text step in square brackets, enclosing each value in double quotes and separating them with commas. When using Find text in this manner, the step will fail if at least one of these is not present on the page.
*** ### Pause This test step can be helpful when you need to wait for some element to appear on a page or want to check what will happen after a specific time. You need to provide a number in seconds that a test must wait before going to the next step.
*** ### Upload file You can use this step to upload a file (**max size 10MB**) to the site you're testing. To use this: 1. click on the highlighted button in the "Upload file" step 2. follow a dialog window that poped up and select the file in your system 3. provide a selector of an **input\[type="file"]** element you want to upload your file to

Click on the highlighted button to open the dialog window and select a file

The file you preload to DogQ will only be used in the corresponding step and will be deleted if the step or Scenario is deleted. {% hint style="info" %} Please, keep in mind that **Upload file** may not always produce the expected results when used with hidden and/or heavily customized inputs. {% endhint %} *** ### Set variable With this step you can create a variable, assign a value to it and then plug it in whenever you need that value inside your Scenario. "Set variable" has two fields, the first one is for the variable name. Names can include letters, digits and underscore. The second field takes in a string value or a JavaScript expression (plain JS, without any references to any libraries or frameworks). To use this: 1. add "Set variable" step 2. specify a name for the variable (letters, digits and underscore) 3. provide a string value or a valid JavaScript expression 4. when using the variable, preface its name with a dollar sign **$**
The value should correspond with the step type you will be using the variable with, e.g., if you're using a variable with Click step it should be something that DogQ can use as a selector, if you're plugging it into Go to URL step, the value should be a URL address, etc.
*** ### Cookies Since cookies are so widespread and in some cases integral to the proper functioning of a website, testing them can become essential. This step enables you to interact with the cookies on your website. Its 6 subtypes include both actions and assertions: #### Cookies Set Assigns value to a cookie with the specified name.
#### Cookies Delete Deletes a cookie with the specified name.
#### Cookies Check Asserts that the cookie with the specified name contains the exact value.
{% hint style="info" %} One step interacts with one cookie. If you have multiple cookies to validate, you will have to check them one by one. {% endhint %} #### Cookies Exist Asserts that the cookie with the specified name exists.

Will fail if no cookie with such name exists

#### Cookies Absent Asserts that the cookie with the specfied name doesn't exist.

Will fail if a cookie with such name exists

#### Allowed list This variant accepts a comma-separated list of cookies' names and asserts that no other cookies are set, i.e. only the specified cookies exist. If you pass "a,b,c" and upon visiting the website cookies "b,c,d" are set, the step will fail.

Will fail if there are any other cookies besides the specified cookie names

*** ### Email This step creates a temporary mailbox that exists only in the context of the test and can be used for verifying email-related functionality, like checking email text content or simply having a random email that you can use to test the sign up flow. #### Email Assign This variant creates the actual mailbox. You can think of it as a variable, give it a name which you can then use to interact with the email in the test. In the example below we are creating a mailbox and naming the variable *test\_email*, then in steps 3 and 4 we are finding the necessary input field and populating it with our email via the variable.
In the test run report we can see that the email DogQ created looked like this:
#### Email Find With this step DogQ goes to the mailbox generated with Email Assign (if you've created multiple mailboxes, it will interact with the last one) and checks the text content of the emails inside. The step passes if the value you provide has a match in either the **body** of the email, the sender's **email address** or the **subject** of the email and fails otherwise.

Checking the sender's email address, the subject and some text from the body of the email received by the auto-generated mailbox.

{% hint style="warning" %} If you have multiple mailboxes in your test, Email Find will always interact with the one that was created the last before Email Find was used. {% endhint %} --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.dogq.io/documentation/scenario-steps.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.