testdriverai 6.0.23 → 6.0.24-canary.fffd04a.0

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

@@ -3,18 +3,25 @@ title: "wait-for-image"
 sidebarTitle: "wait-for-image"
 description: "Wait until an image matching the description is detected on the screen."
 icon: "clock-three-thirty"
+mode: "wide"
 ---
 
+import Replay from "/snippets/tests/wait-for-image-replay.mdx";
+import Example from "/snippets/tests/wait-for-image-yaml.mdx";
+
+<Replay />
+<Example />
+
 ## 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.                                                                 |
-| `timeout`     | `number` | (Optional) The duration in milliseconds to wait for the image to appear. Default is `5000`. |
+|   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 `10000` (10 seconds). |
 
 ## Example usage
 
@@ -29,12 +36,18 @@ timeout: 5000
 - 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.
 
+<Tip>
+  If you are unable to land on an accurate description or experiencing flaky
+  results, try to upload the image to [chatgpt](https://chatgpt.com) and ask it
+  to describe the image and use the generated `description` to get better
+  accuracy and determinism.
+</Tip>
+
 ## 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.
+The `wait-for-image` command is ideal for synchronizing tests with visual elements that may take time to load.

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

@@ -3,19 +3,26 @@ title: "wait-for-text"
 sidebarTitle: "wait-for-text"
 description: "Wait until the specified text is detected on the screen."
 icon: "clock-nine"
+mode: "wide"
 ---
 
+import Replay from "/snippets/tests/wait-for-text-replay.mdx";
+import Example from "/snippets/tests/wait-for-text-yaml.mdx";
+
+<Replay />
+<Example />
+
 ## Description
 
 The `wait-for-text` command waits until the specified text is detected on the screen. This is useful for ensuring that textual elements are present before proceeding with the next steps in a test.
 
 ## Arguments
 
-| Argument  | Type     | Description                                                                                |
-| --------- | -------- | ------------------------------------------------------------------------------------------ |
-| `text`    | `string` | The text to find on the screen.                                                            |
-| `timeout` | `number` | (Optional) The duration in milliseconds to wait for the text to appear. Default is `5000`. |
-| `method`  | `enum`   | (Optional) The matching algorithm to use. Possible values are `ai` (default) and `turbo`.  |
+| Argument  |   Type   | Description                                                                                            |
+| :-------: | :------: | :----------------------------------------------------------------------------------------------------- |
+|  `text`   | `string` | The text to find on the screen.                                                                        |
+| `timeout` | `number` | (Optional) The duration in milliseconds to wait for the text to appear. Default is `5000` (5 seconds). |
+| `method`  |  `enum`  | (Optional) The matching algorithm to use. Possible values are `ai` and `turbo`. Default is `turbo`     |
 
 ## Example usage
 
@@ -28,10 +35,6 @@ timeout: 5000
 ## Protips
 
 - Use unique and specific text to improve detection accuracy.
-- Choose the appropriate `method` for your use case:
-  - `ai`: More robust for complex or ambiguous text matching (default) using [Set-of-Mark](https://arxiv.org/abs/2310.11441).
-  - `levenshtein`: Compare string similarity using [Levenshtein distance](https://en.wikipedia.org/wiki/Levenshtein_distance).
-  - `turbo`: Ideal for simpler scenarios, combining `ai` & `levenshtein`
 - Adjust the `timeout` value based on the expected load time of the text to avoid unnecessary delays.
 
 ## Gotchas
@@ -39,7 +42,6 @@ timeout: 5000
 - If the text doesn't appear within the specified `timeout`, the command will fail.
 - Ensure the text matches exactly, as variations in font size, style, or screen resolution may affect detection accuracy.
 
-## Notes
+---
 
-- The `wait-for-text` command is ideal for synchronizing tests with textual elements that may take time to load.
-- This command supports flexible matching algorithms to accommodate different scenarios.
+The `wait-for-text` command is ideal for synchronizing tests with textual elements that may take time to load.

package/docs/commands/wait.mdx

@@ -3,8 +3,15 @@ title: "wait"
 sidebarTitle: "wait"
 description: "Pause the execution of the script for a specified duration."
 icon: "clock"
+"mode": "wide"
 ---
 
+import Replay from "/snippets/tests/wait-replay.mdx";
+import Example from "/snippets/tests/wait-yaml.mdx";
+
+<Replay />
+<Example />
+
 ## 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.
@@ -35,4 +42,4 @@ timeout: 5000
 ## Notes
 
 - The `wait` command is ideal for introducing controlled pauses in your test scripts.
-- This command is supported across all platforms for consistent behavior.
+- Whenever you are waiting for something to load, use the [wait-for-text](/commands/wait-for-text) or [wait-for-image](/commands/wait-for-image) commands instead to make the test more efficient.

package/docs/docs.json

@@ -44,13 +44,9 @@
                 "group": "Commands",
                 "icon": "command",
                 "pages": [
-                  "/interactive/assert",
-                  "/interactive/dry",
                   "/interactive/explore",
-                  "/interactive/generate",
                   "/interactive/run",
-                  "/interactive/save",
-                  "/interactive/undo"
+                  "/interactive/save"
                 ]
               }
             ]
@@ -101,6 +97,7 @@
             "group": "Configuration",
             "icon": "desktop",
             "pages": [
+              "/guide/authentication",
               "/guide/variables",
               "/guide/lifecycle",
               "/guide/environment-variables",
@@ -135,7 +132,7 @@
             "icon": "play",
             "pages": [
               "/getting-started/running",
-              "/action/setup",
+              "/getting-started/ci",
               "/features/parallel-testing",
               "/action/performance",
               "/action/secrets"
@@ -199,6 +196,7 @@
     "links": [
       {
         "label": "Discord",
+        "icon": "discord",
         "href": "https://discord.com/invite/cWDFW8DzPm"
       }
     ],

package/docs/exporting/junit.mdx

@@ -104,7 +104,7 @@ jobs:
       - uses: actions/checkout@v4
 
       - name: Run TestDriver Tests
-        run: npx testdriverai@latest run testdriver/test.yaml --headless --junit=test-results.xml
+        run: npx testdriverai@latest run testdriver/test.yaml --junit=test-results.xml
         env:
           TD_API_KEY: ${{ secrets.TD_API_KEY }}
 
@@ -127,7 +127,7 @@ pipeline {
         stage('Test') {
             steps {
                 script {
-                    sh 'npx testdriverai@latest run testdriver/test.yaml --headless --junit=junit-results.xml'
+                    sh 'npx testdriverai@latest run testdriver/test.yaml --junit=junit-results.xml'
                 }
             }
             post {
@@ -145,7 +145,7 @@ pipeline {
 ```yaml
 test:
   script:
-    - npx testdriverai@latest run testdriver/test.yaml --headless --junit=test-results.xml
+    - npx testdriverai@latest run testdriver/test.yaml --junit=test-results.xml
   artifacts:
     when: always
     reports:

package/docs/exporting/playwright.mdx

@@ -57,7 +57,7 @@ jobs:
           ref: ${{ github.event.ref }}
 
       - name: Run TestDriver
-        run: npx testdriverai@latest run testdriver/test.yaml --headless
+        run: npx testdriverai@latest run testdriver/test.yaml
         env:
           TD_API_KEY: ${{ secrets.TD_API_KEY }}
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
@@ -87,7 +87,7 @@ TestDriver CLI executes the test file in headless mode. The test file should con
 
 ```yaml
 - name: Run TestDriver
-  run: npx testdriverai@latest run testdriver/test.yaml --headless
+  run: npx testdriverai@latest run testdriver/test.yaml
   env:
     TD_API_KEY: ${{ secrets.TD_API_KEY }}
     GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

package/docs/features/auto-healing.mdx

@@ -68,7 +68,7 @@ When running with `--heal` and `--write`, TestDriver will update the test files
 </Step>
 
 <Step title="Self-Healing">
-  - The AI detects the failure and searches for a similar element.
+  - The AI detects the failure and searches for a similar element based on the `description`.
   - It identifies the "Send" button as the updated element and retries the action.
 </Step>
 <Step title="Test Update">
@@ -109,8 +109,8 @@ jobs:
       - name: Check out repository
         uses: actions/checkout@v4
 
-      - name: Run TestDriver with Self-Healing
-        run: npx testdriverai@latest run testdriver/onboarding.yaml --heal --write --headless
+      - name: Run TestDriver with Auto-Healing
+        run: npx testdriverai@latest run testdriver/onboarding.yaml --heal --write
         env:
           TD_API_KEY: ${{ secrets.TD_API_KEY }}
 

package/docs/features/generation.mdx

@@ -5,9 +5,7 @@ description: "Simplify test creation with AI-driven exploratory testing."
 icon: "wand-sparkles"
 ---
 
-import YmlWarning from "/snippets/yml-warning.mdx";
-
-Writing tests can be a tedious and time-consuming task. TestDriver can generate tests just by exploring your app\! This guide will show you how to generate tests using TestDriver.
+Writing tests can be a tedious and time-consuming task. TestDriver can generate tests just by exploring your app. This guide will show you how to generate tests using TestDriver.
 
 # Generate exploratory tests
 
@@ -21,7 +19,7 @@ TestDriver will boot up.
 
 ```bash
 ❯ testdriverai
-Howdy! I'm TestDriver v5.3.11
+Howdy! I'm TestDriver v6.0.0
 ```
 
 Ensure your website or app is visible on your test runner's display.

package/docs/features/parallel-testing.mdx

@@ -75,17 +75,8 @@ jobs:
         with:
           fetch-depth: 0
 
-      - name: Set up Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: "20"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: NODE_ENV=production npm ci
-
       - name: Run test in headless mode
-        run: npx testdriverai@latest run testdriver/acceptance/${{ matrix.test }} --headless
+        run: npx testdriverai@latest run testdriver/acceptance/${{ matrix.test }}
         env:
           FORCE_COLOR: 3
           TD_API_KEY: ${{ secrets.TD_API_KEY }}
@@ -108,7 +99,6 @@ jobs:
 2. **`run-tests` Job**:
 
    - Uses the matrix strategy to dynamically create a job for each test file.
-   - Sets up Node.js and installs dependencies for TestDriver CLI.
    - Runs each test file in parallel using `npx testdriverai@latest` with the `--headless` flag.
    - The `max-parallel` setting limits the number of tests that can run in parallel to `8` (the max instances for the [Medium Team Plan](https://testdriver.ai/pricing)).
 
@@ -120,8 +110,8 @@ jobs:
 4. **Environment Variables**:
 
    - `TD_API_KEY`: Your TestDriver API key for authentication.
-   - `TD_WEBSITE`: The target website URL for testing.
-   - `TD_THIS_FILE`: The current test file being executed.
+   - `TD_WEBSITE`: The target website URL for testing if its a web application.
+   - `TD_THIS_FILE`: The current test file being executed, this will also be the title of the test recording.
 
 5. **Fail-Fast**:
 

package/docs/features/reusable-snippets.mdx

@@ -34,7 +34,7 @@ Reusable snippets are YAML files containing a set of test steps that perform a s
 Save a YAML file containing the reusable steps. For example, create a `snippets/login.yaml` file for logging into an application:
 
 ```yaml
-version: 4.2.18
+version: 6.0.0
 steps:
   - prompt: Log in to the application
     commands:
@@ -63,7 +63,7 @@ steps:
 Use the [`run`](/commands/run) command to include the snippet in your main test file. For example:
 
 ```yaml
-version: 4.2.18
+version: 6.0.0
 steps:
   - prompt: Log in and navigate to the dashboard
     commands:
@@ -95,7 +95,7 @@ TD_PASSWORD=your_password
 You can chain multiple snippets together to create complex workflows. For example:
 
 ```yaml
-version: 4.2.18
+version: 6.0.0
 steps:
   - prompt: Log in, search for a product, and add it to the cart
     commands:

package/docs/features/selectorless.mdx

@@ -18,7 +18,7 @@ Instead, TestDriver uses natural language prompts and AI-powered vision to inter
 The following is an example of a TestDriver test.
 
 ```yaml
-version: 4.2.18
+version: 6.0.0
 steps:
   - prompt: Click the "Sign Up" button
     commands:
@@ -44,7 +44,7 @@ If the button text changes to "Register," TestDriver's AI vision will still loca
 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
-version: 4.2.18
+version: 6.0.0
 steps:
   - prompt: Click the "Register" button
     commands:
@@ -54,6 +54,12 @@ steps:
         action: click
 ```
 
+<Note>
+  Need to add `--heal` flag during the run command to enable auto-healing of the
+  tests. Refer the [Auto-Healing](/getting-started/running#auto-healing) section
+  to know more.
+</Note>
+
 ## Why selectorless testing?
 
 Traditional testing frameworks rely on selectors tightly coupled to the codebase.

package/docs/features/visual-assertions.mdx

@@ -99,7 +99,7 @@ Visual assertions in TestDriver allow you to validate that your application beha
 
 ```yaml
 - command: assert
-  expect: "The chatbot response is displayed correctly"
+  expect: The chatbot response is displayed correctly
 ```
 
 ### Example: Asserting an image is present
@@ -113,7 +113,7 @@ Visual assertions in TestDriver allow you to validate that your application beha
 
 ```yaml
 - command: assert
-  expect: "The video is playing"
+  expect: The video is playing
 ```
 
 ---

package/docs/getting-started/ci.mdx

@@ -9,7 +9,8 @@ This guide explains how to set up TestDriver in CI/CD pipelines, using **GitHub
 
 ## Prerequisites
 
-1. **TestDriver API Key**: Obtain your API key from TestDriver and store it as a CI/CD secret (for example, `TD_API_KEY` in GitHub Actions).
+1. **Add API key to secrets**: Obtain your API key from TestDriver and store it as a [CI/CD secret](https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets) as `TD_API_KEY`.
+   Also make sure to add the `TD_WEBSITE` secret to the repository with the value of the website you are testing if its a web based application.
 2. **Test Files**: Ensure your test files are saved in the `testdriver/` directory of your repository.
 
 ## Create a CI/CD workflow
@@ -17,6 +18,12 @@ This guide explains how to set up TestDriver in CI/CD pipelines, using **GitHub
 This example uses GitHub Actions, but the same approach can be adapted for other CI/CD platforms:
 
 1. Create a new file in your repository: `.github/workflows/testdriver.yaml`.
+
+<Note>
+  If you have already [initialized the project](/getting-started/setup) with
+  `npx testdriverai@latest init`, the workflow file will already be created.
+</Note>
+
 2. Add the following workflow configuration:
 
 ### Example GitHub Actions workflow
@@ -30,67 +37,25 @@ on:
   pull_request:
   workflow_dispatch:
   schedule:
-    - cron: '0 13 * * *'  # Every day at 1 PM UTC (adjust if needed for timezone)
+    - cron: "0 13 * * *" # Every day at 1 PM UTC (adjust if needed for timezone)
 
 permissions:
-  actions: read
   contents: read
-  statuses: write
-  pull-requests: write
+  pull-requests: read
 
 jobs:
-  gather-test-files:
-    name: Setup Test Matrix (./testdriver/*.yaml)
-    runs-on: ubuntu-latest
-    outputs:
-      test_files: ${{ steps.test_list.outputs.files }}
-    steps:
-      - name: Check out repository
-        uses: actions/checkout@v4
-        with:
-          ref: ${{ github.event.ref }}
-      - name: Find all test files and extract filenames
-        id: test_list
-        run: |
-          FILES=$(ls ./testdriver/*.yaml)
-          FILENAMES=$(basename -a $FILES)
-          FILES_JSON=$(echo "$FILENAMES" | jq -R -s -c 'split("\n")[:-1]')
-          echo "files=$FILES_JSON" >> $GITHUB_OUTPUT
-
   test:
-    needs: gather-test-files
-    strategy:
-      matrix:
-        test: ${{ fromJson(needs.gather-test-files.outputs.test_files) }}
-      fail-fast: false
-    name: ${{ matrix.test }}
+    name: TestDriver
+    runs-on: ubuntu-latest
     steps:
-      - name: Check out repository
+      - name: Checkout repository
         uses: actions/checkout@v4
-        with:
-          ref: ${{ github.event.ref }}
-          fetch-depth: 0
-
-      - name: Set up Node.js
-        uses: actions/setup-node@v4
-        with:
-          node-version: "20"
-          cache: "npm"
-
-      - name: Install dependencies
-        run: NODE_ENV=production npm ci
-
-      - name: Display filename being tested
-        run: echo "Running job for file: ${{ matrix.test }}"
 
       - name: Run TestDriver
-        run: npx testdriverai@latest run testdriver/${{ matrix.test }} --headless
+        run: npx testdriverai@latest run testdriver/testdriver.yaml
         env:
           TD_API_KEY: ${{ secrets.TD_API_KEY }}
-          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-          FORCE_COLOR: "3"
-          TD_WEBSITE: ${{ vars.TD_WEBSITE || 'https://your-app.com' }}
-          TD_THIS_FILE: ${{ matrix.test }}
+          TD_WEBSITE: ${{ secrets.TD_WEBSITE }}
 ```
 
 ## Trigger the workflow
@@ -102,7 +67,12 @@ jobs:
 ## View results
 
 1. Navigate to the **Actions** tab in your GitHub repository (or equivalent CI/CD dashboard).
-2. Select the workflow run to view the test results.
+2. Select the workflow run to view the test results. You will also find the link to the test recording at the end of the run, the url is of the format: `https://app.dashcam.io/replay/1234567890`
+
+<Tip>
+  You can also intregate our supported [reporting platform](/exporting/junit) to
+  get more currated results.
+</Tip>
 
 <Note>
   For other CI/CD platforms, adapt the workflow syntax to match your platform's
@@ -153,3 +123,24 @@ TestDriver provides a powerful debugging interface through its platform. This in
 
 - Share test results with your team by generating a shareable link.
 - Add comments or annotations to specific steps to facilitate discussions and debugging.
+
+---
+
+## How it works
+
+1. **Trigger**: The GitHub workflow is triggered based on the conditions defined in the `on` section.
+2. **Fetch the test files**: The test files are fetched from the repository based off the current branch.
+3. **Running the tests**: The TestDriver CLI is installed and the tests are run via the [`run`](/commands/run) command.
+4. **Authentication**: The `TD_API_KEY` environment variable authenticates your account.
+5. **Dashcam Recording**: Dashcam begins recording the test execution.
+6. **Test Execution**: The TestDriver CLI executes your commands on the cloud VM.
+7. **Test Summary**: TestDriver summarizes the test and sets the exit code based on the pass or fail state.
+8. **Cleanup**: The recording is uploaded to the TestDriver platform and the VM is destroyed, and all data is wiped.
+
+---
+
+## Additional features
+
+- **Parallel testing**: You can run multiple tests in [parallel](/features/parallel-testing#setting-up-parallel-testing-with-a-matrix-strategy). The number of parallel instances depends on the plan you are on.
+- **Environment Variables**: Pass [custom environment variables](guide/authentication#step-2%3A-pass-credentials-to-the-workflow) to configure credentials that are required for the tests.
+- **Chaining Workflows**: A common workflow involves waiting for staging to deploy and testing against the staging environment by passing in the deployed url as `TD_WEBSITE` or the staging build's installation url depending on the kind of application you are testing.

package/docs/getting-started/cli.mdx

@@ -6,8 +6,6 @@ icon: "download"
 mode: "wide"
 ---
 
-import Comments from "/snippets/comments.mdx";
-
 <Steps>
   <Step title="Set up your environment">
       
@@ -46,7 +44,7 @@ import Comments from "/snippets/comments.mdx";
       - prompt: complete checkout
     ```
 
-    Each step has a `prompt` that describes what the agent should do. The agent will use the prompt to generate [commands](/commands) that make the tests faster and more reliable the next time you run the test.
+    Each step has a `prompt` that describes what the agent should do. The agent will use the prompt to generate [commands](/commands/assert) that make the tests faster and more reliable the next time you run the test.
 
   </Step>
   <Step title="Generate test steps from prompts">
@@ -54,7 +52,7 @@ import Comments from "/snippets/comments.mdx";
     Run the following command to run the test file. TestDriver will spawn a virtual machine, launch the sandbox test page, and execute the steps defined in the `example.yaml` file.
 
     ```bash
-    npx testdriverai@beta run example.yaml --write --heal
+    npx testdriverai@latest run example.yaml --write --heal
     ```
 
     The `--write` flag tells TestDriver to save any generated commands to the test file, and the `--heal` flag allows TestDriver to recover from unexpected issues during the test run.
@@ -63,8 +61,7 @@ import Comments from "/snippets/comments.mdx";
   <Step title="Run a regression test">
 
     ```yaml
-      version: 5.7.7
-      session: 682f6071811bd5a322c0e6dd
+      version: 6.0.0
       steps:
         - prompt: focus chrome
           commands:
@@ -92,6 +89,3 @@ import Comments from "/snippets/comments.mdx";
 
   </Step>
 </Steps>
-
-<Comments />
-```

package/docs/getting-started/editing.mdx

@@ -5,12 +5,8 @@ description: "Edit previously generated tests."
 icon: "file-pen"
 ---
 
-import YmlWarning from "/snippets/yml-warning.mdx";
-
 Test scripts are written in YAML format, making them easy to read and modify manually if you need to.
 
-<YmlWarning />
-
 <Card title="Commands Reference" icon="link" href="/commands/assert">
   Explore the available commands and their parameters.
 </Card>
@@ -27,12 +23,12 @@ Use your preferred text editor or IDE (for example, Visual Studio Code) to open
 
 Each test file consists of:
 
-- **Version**: Specifies the TestDriver version.
+- **Version**: Specifies the TestDriver version that was used to generate the test file. This is used to lock the version of TestDriver that is used to run the test.
 - **Session**: A unique identifier for the test session.
 - **Steps**: A list of prompts and commands to execute.
 
-```yaml testfile.yaml
-version: 4.2.18
+```yaml test-file.yaml
+version: 6.0.0
 session: abc1234
 steps:
   - prompt: Open Google Chrome and navigate to Airbnb
@@ -46,7 +42,8 @@ steps:
       - command: type
         text: airbnb.com
       - command: press-keys
-        keys: [enter]
+        keys:
+          - enter
 ```
 
 <Tip>
@@ -61,7 +58,7 @@ steps:
 You can add, edit, or remove steps as needed. Each step contains:
 
 - **Prompt**: A description of the action.
-- **Commands**: The specific actions to perform.
+- **Commands**: The specific actions to perform. It is an **optional** field, meaning, if there are no `commands` the AI considers the `prompt` and generates and executes the yaml on-the-go using the [exploratory mode](/interactive/explore)
 
 #### Example edits:
 
@@ -86,7 +83,13 @@ Ensure the YAML file is properly formatted:
 
 - Use consistent indentation (2 spaces recommended).
 - Avoid trailing spaces or tabs.
-- Validate the file using a YAML linter if needed.
+- TestDriver will validate the yaml syntax and provide suggestions to fix any errors when you run the test.
+
+<Tip>
+  It is recommended to use our [VS Code extension](/getting-started/vscode)
+  while you are editing the yaml. It will provide you with a rich experience
+  with auto-completion, syntax highlighting, and validation.
+</Tip>
 
 ### Test the changes
 

package/docs/getting-started/running.mdx

@@ -17,6 +17,11 @@ npx testdriverai@latest run path/to/test.yaml
 
 This will execute the test script located at `path/to/test.yaml`. If the test passes, the command will exit with a status code of `0`. If it fails, the command will exit with a status code of `1`.
 
+<Note>
+  The path to the test file provided should be relative to the current working
+  directory.
+</Note>
+
 ### Interactive mode
 
 To run a test interactively:
@@ -24,13 +29,13 @@ To run a test interactively:
 1. Launch the TestDriver CLI:
 
 ```bash
-npx testdriverai@latest
+npx testdriverai@latest edit
 ```
 
 2. At the `>` prompt, type:
 
 ```bash
-/run path/to/test.yaml
+> /run path/to/test.yaml
 ```
 
 ## Notes