testdriverai 6.0.16-canary.f0eefe0.0 → 6.0.16

package/docs/commands/if.mdx

@@ -6,16 +6,19 @@ icon: "split"
 ---
 
 ## Description
+
 The `if` command is used to conditionally execute a set of commands based on whether a specified condition evaluates to true or false. If the condition is true, the commands in the `then` block are executed. Otherwise, the commands in the `else` block are executed.
 
 ## Arguments
-| Argument    | Type              | Description                                                                 |
-|-------------|-------------------|-----------------------------------------------------------------------------|
-| `condition` | `string`          | The condition to evaluate.                                                 |
-| `then`      | `list of commands`| The commands to run if the condition is true.                              |
-| `else`      | `list of commands`| The commands to run if the condition is false.                             |
+
+| Argument    | Type               | Description                                    |
+| ----------- | ------------------ | ---------------------------------------------- |
+| `condition` | `string`           | The condition to evaluate.                     |
+| `then`      | `list of commands` | The commands to run if the condition is true.  |
+| `else`      | `list of commands` | The commands to run if the condition is false. |
 
 ## Example usage
+
 ```yaml
 command: if
 condition: the text "Accept Cookies" is visible
@@ -32,15 +35,17 @@ else:
 ```
 
 ## Protips
+
 - Ensure the `condition` is clearly defined and evaluates correctly to avoid unexpected behavior.
 - Use descriptive `then` and `else` blocks to handle both outcomes effectively.
 - Combine the `if` command with other commands like `hover-text` or `focus-application` to create dynamic workflows.
 
 ## Gotchas
+
 - If the `condition` is invalid or can't be evaluated, the command will fail.
 - Ensure all commands in the `then` and `else` blocks are valid and properly formatted.
 
 ## Notes
+
 - The `if` command is useful for creating conditional logic in your tests, allowing for more dynamic and flexible workflows.
 - Both the `then` and `else` blocks are optional, but at least one must be provided.
-

package/docs/commands/match-image.mdx

@@ -6,22 +6,25 @@ icon: "images"
 mode: "wide"
 ---
 
-import Replay from '/snippets/tests/match-image-replay.mdx'
-import Example from '/snippets/tests/match-image-yaml.mdx'
+import Replay from "/snippets/tests/match-image-replay.mdx";
+import Example from "/snippets/tests/match-image-yaml.mdx";
 
 <Replay />
 <Example />
 
 ## Description
+
 The `match-image` command is used to locate an image on the screen by matching it with a reference image file and performing an action (For example, click or hover) at its center. This command is particularly useful for interacting with elements that the AI has difficulty locating using descriptions or other methods.
 
 ## Arguments
-| Argument       | Type     | Description                                                                 |
-|----------------|----------|-----------------------------------------------------------------------------|
-| `path`         | `string` | The relative path to the image file that needs to be matched on the screen. don't include `testdriver/screenshots/*/` in the path. |
-| `action`       | `string` | The action to perform when the image is found. Available actions are: `click` or `hover`. The action will be performed at the center of the matched image. |
+
+| Argument | Type     | Description                                                                                                                                                |
+| -------- | -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `path`   | `string` | The relative path to the image file that needs to be matched on the screen. don't include `testdriver/screenshots/*/` in the path.                         |
+| `action` | `string` | The action to perform when the image is found. Available actions are: `click` or `hover`. The action will be performed at the center of the matched image. |
 
 ## Example usage
+
 ```yaml
 command: match-image
 path: button.png
@@ -29,11 +32,13 @@ action: click
 ```
 
 ## How it works
+
 - The `match-image` command takes a screenshot of the desktop and searches for the location of the reference image within the screenshot.
 - The matching logic looks for the most similar image within the screenshot, not an exact match. If the similarity is below ~80%, it will search additional scales. If no match is found, the command will fail.
 - Screenshots should be stored in the `testdriver/screenshots/(mac/linux/windows)/` directory. TestDriver dynamically resolves the correct image based on the current platform.
 
 ## Protips
+
 - To create high-quality screenshots for matching:
   - Download the video of the test and open it at "full" or "actual" size on your computer.
   - Use a screenshot tool (like Cleanshot X) to capture the target element.
@@ -41,11 +46,13 @@ action: click
 - Ensure the image file is clear and free of unnecessary visual noise to improve matching accuracy.
 
 ## Gotchas
+
 - If the image match is below ~80% similarity, the command will fail.
 - Variations in screen resolution, scaling settings, or platform-specific UI differences may affect matching accuracy.
 - Ensure the image file is stored in the correct directory structure (`testdriver/screenshots/(mac/linux/windows)/`) for dynamic resolution.
 
 ## Notes
+
 - The `match-image` command is ideal for interacting with visual elements that can't be reliably described or located using other commands like `hover-image`.
 - This command supports flexible scaling to account for minor differences in image size or resolution.
 - Use this command as a fallback when other methods fail to locate the desired element.

package/docs/commands/remember.mdx

@@ -6,35 +6,40 @@ icon: "brain"
 ---
 
 ## Description
+
 The `remember` command is used to save a variable for later use. This is useful for storing values that you want to reference in subsequent commands or steps, especially for things that are dynamic or change frequently from run to run.
 
 **The `remember` command is only availble form `v5.7.0` and later.**
 
 ## Arguments
-| Argument | Type                | Description                                                                 |
-|----------|---------------------|-----------------------------------------------------------------------------|
-| `output`   | string | the variable name you will use to recall the value later. |
-| `description`   | string | A prompt describing the value you want to store. |
 
+| Argument      | Type   | Description                                               |
+| ------------- | ------ | --------------------------------------------------------- |
+| `output`      | string | the variable name you will use to recall the value later. |
+| `description` | string | A prompt describing the value you want to store.          |
 
 ---
 
 ## Example usage
+
 ```yaml
 - command: remember
   output: my_variable
   description: The date value shown to the right or 'Order Date'
 ```
+
 ## Protips
+
 - Use the output later with this syntax `${OUTPUT.my_variable}`.
 - The `remember` command does not persist variables across different test runs. If you need to store values for later use in different test runs, consider using external storage solutions or environment variables.
 - For now, the `remember` command only supports string values. If you need to store complex data types, you may use `remember` multiple times for the values. This may change in a later version.
 
 ## Gotchas
+
 - The `remeember` command is only available from `v5.7.0` and later.
 - Ensure the variable name is unique to avoid overwriting existing variables.
 - The variable name is case-sensitive, so `my_variable` and `My_Variable` would be treated as different variables.
 
 ## Notes
-- The `remember` command is ideal for storing values that are generated during the test run, such as timestamps, IDs, the text value of a link you might click later, or any other dynamic data.
 
+- The `remember` command is ideal for storing values that are generated during the test run, such as timestamps, IDs, the text value of a link you might click later, or any other dynamic data.

package/docs/commands/run.mdx

@@ -6,27 +6,33 @@ icon: "play"
 ---
 
 ## Description
+
 The `run` command is used to embed and execute another file within the current script. This is useful for reusing common sequences of commands or modularizing your scripts for better organization and maintainability.
 
 ## Arguments
-| Argument | Type     | Description                                                                 |
-|----------|----------|-----------------------------------------------------------------------------|
+
+| Argument | Type     | Description                                                                                   |
+| -------- | -------- | --------------------------------------------------------------------------------------------- |
 | `file`   | `string` | The path to the file to embed and run. Should be relative to the root of your git repository. |
 
 ## Example usage
+
 ```yaml
 command: run
 file: path/to/another-script.yaml
 ```
 
 ## Protips
+
 - Use the `run` command to centralize reusable logic, such as login flows or setup steps, into separate files.
 - Ensure the file path is correct and relative to the root of your git repository to avoid errors.
 
 ## Gotchas
+
 - If the specified file doesn't exist or contains errors, the command will fail.
 - Ensure the embedded file is compatible with the current script's context, such as variable dependencies or session requirements.
 
 ## Notes
+
 - The `run` command is ideal for creating modular and maintainable test scripts by reusing common workflows.
 - This command supports nesting, allowing you to call scripts that themselves use the `run` command.

package/docs/commands/type.mdx

@@ -6,34 +6,40 @@ icon: "typewriter"
 mode: "wide"
 ---
 
-import Replay from '/snippets/tests/type-replay.mdx'
-import Example from '/snippets/tests/type-yaml.mdx'
+import Replay from "/snippets/tests/type-replay.mdx";
+import Example from "/snippets/tests/type-yaml.mdx";
 
 <Replay />
 <Example />
 
 ## Description
+
 The `type` command is used to simulate typing a string using keyboard emulation. This is useful for entering text into input fields or performing text-based interactions.
 
 ## Arguments
-| Argument | Type     | Description                     |
-|---------|----------|---------------------------------|
-| `text`  | `string` | The text string to type.        |
+
+| Argument | Type     | Description              |
+| -------- | -------- | ------------------------ |
+| `text`   | `string` | The text string to type. |
 
 ## Example usage
+
 ```yaml
 command: type
 text: Hello World
 ```
 
 ## Protips
+
 - Use this command to input text into fields, such as search bars or forms.
 - Ensure the target application or input field is in focus before using the `type` command to avoid unexpected behavior.
 
 ## Gotchas
+
 - If the input field isn't active or in focus, the text may not be typed correctly.
 - Special characters in the `text` string may require additional handling depending on the application.
 
 ## Notes
+
 - The `type` command is ideal for automating text input in tests.
 - This command supports cross-platform compatibility for consistent behavior across operating systems.

package/docs/commands/wait-for-image.mdx

@@ -6,15 +6,18 @@ icon: "clock-three-thirty"
 ---
 
 ## Description
+
 The `wait-for-image` command waits until the specified image is detected on the screen. This is useful for ensuring that visual elements are present before proceeding with the next steps in a test.
 
 ## Arguments
-| Argument      | Type     | Description                                                                 |
-|---------------|----------|-----------------------------------------------------------------------------|
-| `description` | `string` | A description of the image.                                                |
+
+| Argument      | Type     | Description                                                                                 |
+| ------------- | -------- | ------------------------------------------------------------------------------------------- |
+| `description` | `string` | A description of the image.                                                                 |
 | `timeout`     | `number` | (Optional) The duration in milliseconds to wait for the image to appear. Default is `5000`. |
 
 ## Example usage
+
 ```yaml
 command: wait-for-image
 description: trash icon
@@ -22,13 +25,16 @@ timeout: 5000
 ```
 
 ## Protips
+
 - Use clear and concise descriptions for the image to improve detection accuracy.
 - Adjust the `timeout` value based on the expected load time of the image to avoid unnecessary delays.
 
 ## Gotchas
+
 - If the image doesn't appear within the specified `timeout`, the command will fail.
 - Ensure the description accurately represents the image to avoid detection issues.
 
 ## Notes
+
 - The `wait-for-image` command is ideal for synchronizing tests with visual elements that may take time to load.
 - This command supports flexible timeouts to accommodate varying load times.

package/docs/commands/wait.mdx

@@ -6,28 +6,33 @@ icon: "clock"
 ---
 
 ## Description
+
 The `wait` command pauses the execution of the script for a specified number of milliseconds before continuing. This is useful for adding delays between commands or waiting for certain conditions to stabilize.
 
 ## Arguments
-| Argument  | Type     | Description                              |
-|-----------|----------|------------------------------------------|
-| `timeout` | `number` | The duration in milliseconds to wait.    |
+
+| Argument  | Type     | Description                           |
+| --------- | -------- | ------------------------------------- |
+| `timeout` | `number` | The duration in milliseconds to wait. |
 
 ## Example usage
+
 ```yaml
 command: wait
 timeout: 5000
 ```
 
 ## Protips
+
 - Use the `wait` command to handle timing issues, such as waiting for animations to complete or elements to load.
 - Avoid using excessively long timeouts to keep tests efficient.
 
 ## Gotchas
+
 - Overusing the `wait` command can slow down test execution. Use it only when necessary.
 - Ensure the timeout value is appropriate for the scenario to avoid unnecessary delays.
 
 ## Notes
+
 - The `wait` command is ideal for introducing controlled pauses in your test scripts.
 - This command is supported across all platforms for consistent behavior.
-

package/docs/features/generation.mdx

@@ -67,7 +67,7 @@ steps:
 
 Now it's time to generate the regression test.
 
-Run the tests with the `run` command and use the `--write` parameter:
+Run the tests with the [`run`](/commands/run) command and use the `--write` parameter:
 
 ```bash
 npx testdriverai@latest run testdriver/generate/test-error-user-login.yaml --write

package/docs/features/reusable-snippets.mdx

@@ -5,7 +5,7 @@ description: "Discover how to modularize your test workflows using reusable YAML
 icon: "repeat"
 ---
 
-import GitignoreWarning from '/snippets/gitignore-warning.mdx'
+import GitignoreWarning from "/snippets/gitignore-warning.mdx";
 
 Reusable snippets in TestDriver allow you to modularize your test steps by creating smaller, reusable YAML files that can be embedded into larger test workflows. This approach improves test maintainability, reduces duplication, and makes your test suite more organized and scalable.
 
@@ -13,7 +13,7 @@ Reusable snippets in TestDriver allow you to modularize your test steps by creat
 
 ## What are reusable snippets?
 
-Reusable snippets are YAML files containing a set of test steps that perform a specific task, such as logging in, navigating to a page, or setting up test prerequisites. These snippets can be referenced in other test files using the `run` command, enabling you to reuse common actions across multiple tests.
+Reusable snippets are YAML files containing a set of test steps that perform a specific task, such as logging in, navigating to a page, or setting up test prerequisites. These snippets can be referenced in other test files using the [`run`](/commands/run) command, enabling you to reuse common actions across multiple tests.
 
 ---
 
@@ -27,6 +27,7 @@ Reusable snippets are YAML files containing a set of test steps that perform a s
 ---
 
 ## How to create and use reusable snippets
+
 <Steps>
 <Step title="Create a Snippet">
 
@@ -54,11 +55,12 @@ steps:
         description: log in button
         action: click
 ```
+
 </Step>
 
 <Step title="Reference the Snippet in a Test">
 
-Use the `run` command to include the snippet in your main test file. For example:
+Use the [`run`](/commands/run) command to include the snippet in your main test file. For example:
 
 ```yaml
 version: 4.2.18
@@ -72,6 +74,7 @@ steps:
         description: dashboard link in the navigation bar
         action: click
 ```
+
 </Step>
 
 <Step title="Parameterize Inputs">
@@ -87,7 +90,6 @@ TD_PASSWORD=your_password
 </Step>
 </Steps>
 
-
 ## Example: Combining multiple snippets
 
 You can chain multiple snippets together to create complex workflows. For example:
@@ -104,7 +106,8 @@ steps:
       - command: run
         file: snippets/add_to_cart.yaml
 ```
---- 
+
+---
 
 ## Best practices for reusable snippets
 

package/docs/features/selectorless.mdx

@@ -5,7 +5,7 @@ description: "Selectorless testing approach simplifies end-to-end testing by usi
 icon: "eye"
 ---
 
-Selectorless testing eliminates the need for brittle selectors like CSS classes, IDs, or XPath. 
+Selectorless testing eliminates the need for brittle selectors like CSS classes, IDs, or XPath.
 
 Instead, TestDriver uses natural language prompts and AI-powered vision to interact with applications as a user would. This makes tests more resilient to UI changes and reduces maintenance overhead.
 
@@ -32,7 +32,7 @@ steps:
         expect: The registration form is visible
 ```
 
-This allows TestDriver locates the target for `hover-text` based on its context and description. The agent will search for elements: in the following order.
+This allows TestDriver locates the target for [`hover-text`](/commands/hover-text) based on its context and description. The agent will search for elements: in the following order.
 
 - `text` - exact element to match
 - `description` - a description of the element given the exact text isn't found, or there are multiple matches
@@ -40,7 +40,7 @@ This allows TestDriver locates the target for `hover-text` based on its context
 
 ### What happens when "Sign Up" changes to "Register"?
 
-If the button text changes to "Register," TestDriver's AI vision will still locate the button based on its context and description. You don't need to update the test manually. 
+If the button text changes to "Register," TestDriver's AI vision will still locate the button based on its context and description. You don't need to update the test manually.
 TestDriver will then update the test to reflect the new UI by modifying the `text` field. Then, it will open a new pull request with the changes.
 
 ```yaml
@@ -53,15 +53,22 @@ steps:
         description: button in the header for user registration
         action: click
 ```
+
 ## Why selectorless testing?
 
-Traditional testing frameworks rely on selectors tightly coupled to the codebase. 
+Traditional testing frameworks rely on selectors tightly coupled to the codebase.
 For example:
 
 ```javascript
 const button = await page.$('button[class="sign-up-btn"]');
 ```
 
-<Warning>When using legacy frameworks, if the class name changes, the test will break, requiring updates to the test code!</Warning> 
+<Warning>
+  When using legacy frameworks, if the class name changes, the test will break,
+  requiring updates to the test code!
+</Warning>{" "}
 
-<Check>Selectorless testing avoids this by focusing on the intent of the interaction rather than the implementation details.</Check>
+<Check>
+  Selectorless testing avoids this by focusing on the intent of the interaction
+  rather than the implementation details.
+</Check>

package/docs/features/visual-assertions.mdx

@@ -10,71 +10,86 @@ Visual assertions in TestDriver allow you to validate that your application beha
 ## What can TestDriver test with visual assertions?
 
 ### AI chatbots
-  - Validate that chatbot responses are displayed correctly.
-  - Ensure the chatbot interface is accessible and functional.
-  - See [AI Chatbots](/scenarios/ai-chatbot) for an example.
+
+- Validate that chatbot responses are displayed correctly.
+- Ensure the chatbot interface is accessible and functional.
+- See [AI Chatbots](/scenarios/ai-chatbot) for an example.
 
 ### Desktop applications
-  - Verify that desktop app windows, dialogs, and UI elements render as expected.
-  - Test cross-platform compatibility for Windows, Mac, and Linux.
-  - See [Using TestDriver with Desktop Apps](/apps/desktop-apps) for an example.
+
+- Verify that desktop app windows, dialogs, and UI elements render as expected.
+- Test cross-platform compatibility for Windows, Mac, and Linux.
+- See [Using TestDriver with Desktop Apps](/apps/desktop-apps) for an example.
 
 ### Chrome extensions
-  - Confirm that the extension UI integrates properly with the browser.
-  - Validate extension popups, settings, and interactions.
-  - See [Using TestDriver with Chrome Extensions](/apps/chrome-extensions) for an example.
+
+- Confirm that the extension UI integrates properly with the browser.
+- Validate extension popups, settings, and interactions.
+- See [Using TestDriver with Chrome Extensions](/apps/chrome-extensions) for an example.
 
 ### PDF generation
-  - Assert that generated PDFs contain the correct text, images, and formatting.
-  - Verify that PDFs open and display properly in viewers.
-  - See [PDF Generation](/scenarios/pdf-generation) for an example.
+
+- Assert that generated PDFs contain the correct text, images, and formatting.
+- Verify that PDFs open and display properly in viewers.
+- See [PDF Generation](/scenarios/pdf-generation) for an example.
 
 ### Spelling & grammar
-  - Check for spelling and grammar errors in displayed text.
-  - Validate that text content matches expected language rules.
-  - See [Spell Check](/scenarios/spell-check) for an example.
+
+- Check for spelling and grammar errors in displayed text.
+- Validate that text content matches expected language rules.
+- See [Spell Check](/scenarios/spell-check) for an example.
 
 ### Auth signup & login
-  - Ensure OAuth flows display the correct login screens.
-  - Verify that users are redirected to the correct pages after login.
-  - See [Login](/scenarios/log-in) for an example.
+
+- Ensure OAuth flows display the correct login screens.
+- Verify that users are redirected to the correct pages after login.
+- See [Login](/scenarios/log-in) for an example.
 
 ### File system & uploads
-  - Confirm that file upload dialogs appear and function correctly.
-  - Validate that uploaded files are processed and displayed as expected.
-  - See [File Upload](/scenarios/file-upload) for an example.
+
+- Confirm that file upload dialogs appear and function correctly.
+- Validate that uploaded files are processed and displayed as expected.
+- See [File Upload](/scenarios/file-upload) for an example.
 
 ### Image content
-  - Verify that images are displayed correctly and match expected content.
-  - Test for the presence of specific icons, logos, or visual elements.
+
+- Verify that images are displayed correctly and match expected content.
+- Test for the presence of specific icons, logos, or visual elements.
 
 ### Video content
-  - Assert that videos play correctly and match expected visuals.
-  - Validate video controls (play, pause, fullscreen) and captions.
+
+- Assert that videos play correctly and match expected visuals.
+- Validate video controls (play, pause, fullscreen) and captions.
 
 ### OS accessibility features
-  - Test high-contrast modes, screen readers, and other accessibility features.
-  - Validate that UI elements are accessible and readable.
+
+- Test high-contrast modes, screen readers, and other accessibility features.
+- Validate that UI elements are accessible and readable.
 
 ### Light / Dark mode
-  - Verify that the application switches between light and dark modes correctly.
-  - Assert that UI elements are visible and styled appropriately in both modes.
+
+- Verify that the application switches between light and dark modes correctly.
+- Assert that UI elements are visible and styled appropriately in both modes.
 
 ### Privacy configuration
-  - Confirm that privacy settings are displayed and functional.
-  - Validate that toggles, checkboxes, and options reflect the correct state.
+
+- Confirm that privacy settings are displayed and functional.
+- Validate that toggles, checkboxes, and options reflect the correct state.
 
 ### `<iframe>`
-  - Test content rendered inside `<iframe>` elements.
-  - Validate interactions within embedded frames.
+
+- Test content rendered inside `<iframe>` elements.
+- Validate interactions within embedded frames.
 
 ### `<canvas>`
-  - Verify that canvas elements render graphics, charts, or animations correctly.
-  - Assert that dynamic content within the canvas matches expectations.
+
+- Verify that canvas elements render graphics, charts, or animations correctly.
+- Assert that dynamic content within the canvas matches expectations.
 
 ### `<video>`
-  - Ensure video elements load and play correctly.
-  - Validate video overlays, subtitles, and playback controls.
+
+- Ensure video elements load and play correctly.
+- Validate video overlays, subtitles, and playback controls.
 
 ---
 
@@ -85,7 +100,6 @@ Visual assertions in TestDriver allow you to validate that your application beha
 ```yaml
 - command: assert
   expect: "The chatbot response is displayed correctly"
-
 ```
 
 ### Example: Asserting an image is present
@@ -100,8 +114,8 @@ Visual assertions in TestDriver allow you to validate that your application beha
 ```yaml
 - command: assert
   expect: "The video is playing"
-
 ```
+
 ---
 
 ## Benefits of visual assertions

package/docs/getting-started/editing.mdx

@@ -73,7 +73,7 @@ You can add, edit, or remove steps as needed. Each step contains:
   ```
 
 - **Change the URL**:
-  Update the `text` field in the `type` command:
+  Update the `text` field in the [`type`](/commands/type) command:
 
   ```yaml
   - command: type