testdriverai 5.6.3 → 5.6.4

package/docs/features/generation.mdx

@@ -5,9 +5,11 @@ 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.
 
-# Generate Exploratory Tests
+# Generate exploratory tests
 
 Launch `testdriverai` in interactive mode with the following command:
 
@@ -61,7 +63,7 @@ steps:
   - prompt: Assert that there are issues during checkout and an error is displayed.
 ```
 
-# Generate Regression Tests from Exploratory Tests
+# Generate regression tests from exploratory tests
 
 Now it's time to generate the regression test.
 
@@ -80,11 +82,12 @@ No commands found, running exploratory
 
 When using the `--save` command, TestDriver appends any generated commands to the test file.
 
-So as your test run, TestDriver will append successful commands to the yaml file and save it.
+So as your test run, TestDriver will append successful commands to the YAML file and save it.
+
+<YmlWarning/>
 
 ```yaml
 version: 5.3.11
-session: 6801430b5f2c252a8f4bed60
 steps:
   - prompt: Focus the browser window.
     commands:

package/docs/features/github.mdx

@@ -12,18 +12,18 @@ TestDriver offers advanced GitHub integration features, including the ability to
 
 ---
 
-## 1. **Creating Branches Automatically**
+## 1. **Creating branches automatically**
 
 TestDriver can create its own branches to store test results, updates, or auto-healed tests. This ensures that test-related changes are isolated from the main codebase and can be reviewed before merging.
 
-### How It Works:
+### How it works
 
-- **Branch Creation**: TestDriver creates a new branch (e.g., `test-results` or `auto-heal-updates`) during the workflow execution.
-- **Pull Request**: A pull request is automatically opened from the new branch to the base branch (e.g., `main`), allowing developers to review the changes.
+- **Branch Creation**: TestDriver creates a new branch (for example, `test-results` or `auto-heal-updates`) during the workflow execution.
+- **Pull Request**: A pull request is automatically opened from the new branch to the base branch (for example, `main`), allowing developers to review the changes.
 
-### Example Workflow with Branch Creation:
+### Example workflow with branch creation
 
-```yaml {21-24}
+```yaml {21-24} .github/workflows/testdriver.yaml
 name: TestDriver Auto-Healing
 
 on:
@@ -47,34 +47,34 @@ jobs:
           create-pr: true
           pr-title: "TestDriver Test Results"
           pr-branch: test-results
-          pr-test-filename: testdriver-results.yml
+          pr-test-filename: testdriver-results.yaml
         env:
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
           FORCE_COLOR: "3"
 
 ```
 
-### Key Fields:
+### Key fields
 - **`create-pr: true`**: Enables branch creation and pull request generation.
-- **`pr-branch`**: Specifies the branch name (e.g., `test-results`).
+- **`pr-branch`**: Specifies the branch name (for example, `test-results`).
 - **`pr-title`**: Sets the title of the pull request.
 - **`pr-test-filename`**: Specifies the filename for the test results.
 
 ---
 
-## 2. **Manual Workflow Dispatch**
+## 2. **Manual workflow dispatch**
 
 GitHub Actions supports manual triggering of workflows using the **workflow_dispatch** event. This allows you to run TestDriver workflows on demand, making it ideal for exploratory testing or debugging.
 
-### How to Trigger Workflows Manually:
+### How to trigger workflows manually
 1. Navigate to the **Actions** tab in your GitHub repository.
 2. Select the workflow you want to run.
 3. Click the **Run workflow** button.
 4. Provide any required inputs (if applicable) and confirm.
 
-### Example Workflow with Manual Dispatch:
+### Example workflow with manual dispatch
 
-```yaml
+```yaml .github/workflows/testdriver.yaml
 name: TestDriver Manual Dispatch
 
 on:
@@ -103,14 +103,14 @@ jobs:
 
 Run Steps
 
-### Benefits of Manual Dispatch:
+### Benefits of manual dispatch
 - **Exploratory Testing**: Run tests on demand for specific scenarios.
 - **Debugging**: Trigger workflows to debug issues without waiting for automated triggers.
 - **Flexibility**: Test changes in feature branches or experimental setups.
 
 ---
 
-## 3. **GitHub Actions Output**
+## 3. **GitHub Actions output**
 
 TestDriver provides detailed outputs during workflow execution, which are visible in the **Actions** tab of your repository. These outputs include:
 - **Test Summary**: A high-level overview of the test results.
@@ -118,13 +118,13 @@ TestDriver provides detailed outputs during workflow execution, which are visibl
 - **Screenshots and GIFs**: Visual feedback for debugging.
 - **Links to TestDriver Dashcam.io Replays**: Direct links to detailed test recordings and results.
 
-### Example Outputs:
+### Example outputs
 
-#### **Test Summary**:
+#### **Test summary**
 - ✅ All tests passed.
 - ❌ 2 tests failed.
 
-#### **TestDriver Replay**:
+#### **TestDriver Replay**
 
 ```markdown
 [View Full Test Results](https://app.testdriver.ai/...)
@@ -132,10 +132,10 @@ TestDriver provides detailed outputs during workflow execution, which are visibl
 
 ---
 
-### Using Outputs in Workflows:
+### Using Outputs in Workflows
 You can capture and use TestDriver outputs in subsequent steps of your workflow. For example, you can post the test summary as a comment on a pull request.
 
-#### Example:
+#### Example
 
 
 ```yaml
@@ -157,7 +157,7 @@ You can capture and use TestDriver outputs in subsequent steps of your workflow.
 
 ---
 
-## Summary of Features:
+## Summary of Features
 1. **Branch Creation**: Automatically create branches for test results or auto-healed tests.
 2. **Manual Dispatch**: Trigger workflows on demand from the GitHub Actions UI.
 3. **Detailed Outputs**: Access logs, summaries, and visual feedback directly in the Actions tab.

package/docs/features/parallel-testing.mdx

@@ -9,7 +9,7 @@ Parallel testing allows you to run multiple tests simultaneously, significantly
 
 ---
 
-## Why Use Parallel Testing?
+## Why use parallel testing?
 
 1. **Faster Execution**: Run multiple tests at the same time to reduce overall test duration.
 2. **Scalability**: Easily scale your testing efforts as your test suite grows.
@@ -18,12 +18,12 @@ Parallel testing allows you to run multiple tests simultaneously, significantly
 
 ---
 
-## Setting Up Parallel Testing with Matrix Strategy
+## Setting Up parallel testing with a matrix strategy
 
 <Steps>
 <Step titel="Organize Your Test Files">
 
-Ensure your test files are stored in a directory (e.g., `testdriver/`) and follow a consistent naming convention (e.g., `test1.yml`, `test2.yml`, etc.).
+Ensure your test files are stored in a directory (for example, `testdriver/`) and follow a consistent naming convention (for example, `test1.yaml`, `test2.yaml`, etc.).
 
 </Step>
 
@@ -54,7 +54,7 @@ jobs:
       - name: Find all test files
         id: test_list
         run: |
-          FILES=$(ls ./testdriver/*.yml)
+          FILES=$(ls ./testdriver/*.yaml)
           FILES_JSON=$(echo "$FILES" | jq -R -s -c 'split("\n")[:-1]')
           echo "::set-output name=files::$FILES_JSON"
 
@@ -85,7 +85,7 @@ jobs:
 </Steps>
 ---
 
-### Explanation of the Workflow
+### Explanation of the workflow
 
 1. **`gather-test-files` Job**:
   - Collects all test files in the `testdriver/` directory.
@@ -104,7 +104,7 @@ jobs:
 
 ---
 
-## Benefits of Using the Matrix Strategy
+## Benefits of using the matrix strategy
 
 1. **Dynamic Test Distribution**: Automatically adapts to the number of test files.
 2. **Scalable**: Easily handles large test suites by distributing tests across multiple jobs.
@@ -112,15 +112,15 @@ jobs:
 
 ---
 
-## Example Output
+## Example output
 
 When this workflow runs:
-- Each test file (e.g., `test1.yml`, `test2.yml`) is executed in its own job.
+- Each test file (for example, `test1.yaml`, `test2.yaml`) is executed in its own job.
 - The results of all tests are displayed in the GitHub Actions dashboard.
 
 ---
 
-## Best Practices
+## Best practices
 
 1. **Organize Test Files**: Use a consistent naming convention for test files to simplify management.
 2. **Monitor Test Results**: Review the GitHub Actions dashboard to identify and debug failing tests.

package/docs/features/reusable-snippets.mdx

@@ -11,13 +11,13 @@ Reusable snippets in TestDriver allow you to modularize your test steps by creat
 
 ---
 
-## What Are Reusable Snippets?
+## 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.
 
 ---
 
-## Why Use Reusable Snippets?
+## Why use reusable snippets?
 
 1. **Maintainability**: Update a snippet in one place, and all tests using it will automatically reflect the changes.
 2. **Reusability**: Avoid duplicating common actions like login or setup across multiple tests.
@@ -26,7 +26,7 @@ Reusable snippets are YAML files containing a set of test steps that perform a s
 
 ---
 
-## How to Create and Use Reusable Snippets
+## How to create and use reusable snippets
 <Steps>
 <Step title="Create a Snippet">
 
@@ -88,7 +88,7 @@ TD_PASSWORD=your_password
 </Steps>
 
 
-## Example: Combining Multiple Snippets
+## Example: Combining multiple snippets
 
 You can chain multiple snippets together to create complex workflows. For example:
 
@@ -106,17 +106,17 @@ steps:
 ```
 --- 
 
-## Best Practices for Reusable Snippets
+## Best practices for reusable snippets
 
 1. **Organize Snippets**: Store reusable snippets in a dedicated `snippets/` directory for better organization.
-2. **Use Descriptive Names**: Name snippet files clearly (e.g., `login.yaml`, `setup.yaml`) to indicate their purpose.
+2. **Use Descriptive Names**: Name snippet files clearly (for example, `login.yaml`, `setup.yaml`) to indicate their purpose.
 3. **Test Snippets Independently**: Validate each snippet before integrating it into larger workflows.
 4. **Parameterize Inputs**: Use placeholders or environment variables for dynamic data.
 5. **Document Snippets**: Add comments or documentation to explain the purpose and usage of each snippet.
 
 ---
 
-## Benefits of Reusable Snippets
+## Benefits of reusable snippets
 
 - **Efficiency**: Save time by reusing existing logic.
 - **Scalability**: Easily extend your test suite by combining snippets.

package/docs/features/selectorless.mdx

@@ -13,7 +13,7 @@ Instead, TestDriver uses natural language prompts and AI-powered vision to inter
 - Tests are resilient to changes like text updates, class renaming, or minor layout adjustments.
 - By using natural language and AI vision, TestDriver simplifies test creation and maintenance.
 
-## What is Selectorless Testing?
+## What's selectorless testing?
 
 The following is an example of a TestDriver test.
 
@@ -38,10 +38,10 @@ This allows TestDriver locates the target for `hover-text` based on its context
 - `description` - a description of the element given the exact text isn't found, or there are multiple matches
 - `prompt` - a high level prompt used to regenerate the test if no match is found
 
-### What Happens When "Sign Up" Changes to "Register"?
+### 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. 
-TestDriver will then update the test to reflect the new UI by modifing the `text` field. Then, it will open a new pull request with the changes.
+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
@@ -53,7 +53,7 @@ steps:
         description: button in the header for user registration
         action: click
 ```
-## Why Selectorless Testing?
+## Why selectorless testing?
 
 Traditional testing frameworks rely on selectors tightly coupled to the codebase. 
 For example:

package/docs/features/visual-assertions.mdx

@@ -7,57 +7,60 @@ icon: "binoculars"
 
 Visual assertions in TestDriver allow you to validate that your application behaves as expected by analyzing what's displayed on the screen. This approach ensures that your tests mimic real user interactions and verify outcomes visually, making it ideal for testing UI-heavy applications and dynamic content.
 
-## What Can TestDriver Test with Visual Assertions?
+## What can TestDriver test with visual assertions?
 
-<Info>
-    See many of the following examples in the [TestDriver Scenarios](/scenarios/ai-chatbot)
-</Info>
-
-### AI Chatbots
+### 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.
 
-### Desktop Applications
+### 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.
 
-### Chrome Extensions
+### 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.
 
-### PDF Generation
+### 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.
 
-### Spelling & Grammar
+### 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.
 
-### Auth Signup & Login
+### 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.
 
-### File System & Uploads
+### 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.
 
-### Image Content
+### Image content
   - Verify that images are displayed correctly and match expected content.
   - Test for the presence of specific icons, logos, or visual elements.
 
-### Video Content
+### Video content
   - Assert that videos play correctly and match expected visuals.
   - Validate video controls (play, pause, fullscreen) and captions.
 
-### OS Accessibility Features
+### OS accessibility features
   - Test high-contrast modes, screen readers, and other accessibility features.
   - Validate that UI elements are accessible and readable.
 
-### Light / Dark Mode
+### 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.
 
-### Privacy Configuration
+### Privacy configuration
   - Confirm that privacy settings are displayed and functional.
   - Validate that toggles, checkboxes, and options reflect the correct state.
 
@@ -75,9 +78,9 @@ Visual assertions in TestDriver allow you to validate that your application beha
 
 ---
 
-## How to Use Visual Assertions
+## How to use visual assertions
 
-### Example: Asserting Text on the Screen
+### Example: Asserting text on the screen
 
 ```yaml
 - command: assert
@@ -85,14 +88,14 @@ Visual assertions in TestDriver allow you to validate that your application beha
 
 ```
 
-### Example: Asserting an Image is Present
+### Example: Asserting an image is present
 
 ```yaml
 - command: assert
   expect: The company logo appears in the header
 ```
 
-### Example: Asserting Video Playback
+### Example: Asserting video playback
 
 ```yaml
 - command: assert
@@ -101,7 +104,7 @@ Visual assertions in TestDriver allow you to validate that your application beha
 ```
 ---
 
-## Benefits of Visual Assertions
+## Benefits of visual assertions
 
 1. **Selectorless Testing**: No need to rely on brittle selectors or static code.
 2. **Dynamic Adaptation**: Tests adapt to UI changes, reducing maintenance.
@@ -110,7 +113,7 @@ Visual assertions in TestDriver allow you to validate that your application beha
 
 ---
 
-## Best Practices for Visual Assertions
+## Best Practices for visual assertions
 
 1. **Use Descriptive Prompts**: Provide clear descriptions for elements or behaviors you want to test.
 2. **Combine with Other Commands**: Use visual assertions alongside navigation and interaction commands for end-to-end testing.

package/docs/getting-started/ci.mdx

@@ -9,17 +9,17 @@ This guide explains how to set up a basic GitHub Actions workflow to run tests u
 
 ## Prerequisites
 
-1. **TestDriver API Key**: Obtain your API key from TestDriver and store it as a GitHub secret (e.g., `TD_API_KEY`).
+1. **TestDriver API Key**: Obtain your API key from TestDriver and store it as a GitHub secret (for example, `TD_API_KEY`).
 2. **Test Files**: Ensure your test files are saved in the `testdriver/` directory of your repository.
 
-## Create a GitHub Actions Workflow
+## Create a GitHub Actions workflow
 
-1. Create a new file in your repository: `.github/workflows/testdriver.yml`.
+1. Create a new file in your repository: `.github/workflows/testdriver.yaml`.
 2. Add the following workflow configuration:
 
-### Example Workflow: `.github/workflows/testdriver.yml`
+### Example workflow
 
-```yaml
+```yaml .github/workflows/testdriver.yaml [expandable]
 name: TestDriver / Run / Regressions
 
 on:
@@ -38,7 +38,7 @@ permissions:
 
 jobs:
   gather-test-files:
-    name: Setup Test Matrix (./testdriver/*.yml)
+    name: Setup Test Matrix (./testdriver/*.yaml)
     runs-on: ubuntu-latest
     outputs:
       test_files: ${{ steps.test_list.outputs.files }}
@@ -50,7 +50,7 @@ jobs:
       - name: Find all test files and extract filenames
         id: test_list
         run: |
-          FILES=$(ls ./testdriver/*.yml)
+          FILES=$(ls ./testdriver/*.yaml)
           FILENAMES=$(basename -a $FILES)
           FILES_JSON=$(echo "$FILENAMES" | jq -R -s -c 'split("\n")[:-1]')
           echo "::set-output name=files::$FILES_JSON"
@@ -90,49 +90,49 @@ jobs:
           FORCE_COLOR: "3"
 ```
 
-## Trigger the Workflow
+## Trigger the workflow
 
 1. Push changes to the `main` branch or open a pull request.
 2. Alternatively, manually trigger the workflow from the **Actions** tab in your GitHub repository.
 
-## View Results
+## View results
 
 1. Navigate to the **Actions** tab in your GitHub repository.
 2. Select the workflow run to view the test results.
 
-# Debugging Tests
+# Debugging tests
 TestDriver provides a powerful debugging interface through its **app.TestDriver** platform (formerly Dashcam). This interface allows you to analyze test runs, identify failures, and optimize your test suite with detailed visual and textual feedback.
 
-### Step-by-Step Execution Logs
+### 1. Step-by-step execution logs
 - View each step of the test execution, including:
-  - The **action performed** (e.g., clicking a button, typing text).
-  - The **expected outcome** (e.g., verifying a specific element is visible).
+  - The **action performed** (for example, clicking a button, typing text).
+  - The **expected outcome** (for example, verifying a specific element is visible).
   - The **result** (pass, fail, or skipped).
 - Logs provide detailed context for each step, making it easier to pinpoint where and why a test failed.
 
-### 2. Visual Feedback
+### 2. Visual feedback
 - **Screenshots**: See what the application looked like at each step of the test.
 - **GIF Previews**: Watch a replay of the entire test execution to understand the flow and identify UI issues.
 - **Highlighting**: Elements interacted with during the test are highlighted in screenshots, helping you verify that the correct elements were targeted.
 
-### 3. Error Details
+### 3. Error details
 - For failed steps, app.TestDriver provides:
-  - **Error messages**: Detailed descriptions of what went wrong (e.g., "Element not found").
+  - **Error messages**: Detailed descriptions of what went wrong (for example, "Element not found").
   - **Stack traces**: For advanced debugging of backend or script-related issues.
   - **Suggestions**: Recommendations for fixing common issues, such as adjusting prompts or improving element descriptions.
 
-### 4. Test History
+### 4. Test history
 - Access the history of test runs to:
   - Compare results across different builds or environments.
   - Identify flaky tests by analyzing patterns in failures.
   - Track improvements or regressions over time.
 
-### 5. Environment Context
+### 5. Environment context
 - View the environment details for each test run, including:
   - Operating system and browser version.
   - Screen resolution and viewport size.
   - Network conditions (if applicable).
 
-### 6. Collaboration Tools
+### 6. Collaboration tools
 - Share test results with your team by generating a shareable link.
 - Add comments or annotations to specific steps to facilitate discussions and debugging.

package/docs/getting-started/editing.mdx

@@ -5,8 +5,12 @@ 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"
@@ -19,7 +23,7 @@ Test scripts are written in YAML format, making them easy to read and modify man
 TestDriver test files are typically stored in the `testdriver/` directory of your project. The default file is `testdriver/testdriver.yaml`.
 
 ### Open the Test File
-Use your preferred text editor or IDE (e.g., Visual Studio Code) to open the YAML file.
+Use your preferred text editor or IDE (for example, Visual Studio Code) to open the YAML file.
 
 ### YAML Structure
 Each test file consists of:
@@ -27,9 +31,9 @@ Each test file consists of:
 - **Session**: A unique identifier for the test session.
 - **Steps**: A list of prompts and commands to execute.
 
-```yaml
+```yaml testfile.yaml
 version: 4.2.18
-session: abc123
+session: abc1234
 steps:
   - prompt: Open Google Chrome and navigate to Airbnb
     commands:
@@ -45,15 +49,15 @@ steps:
         keys: [enter]
 ```
 
-<Tip>The `version` captured when you generate a test file is the version of TestDriver you used, and is not used when running the test. This does not affect your ability to use newer versions of TestDriver on existing test files nor do these need to be updated when migrating to a new version.</Tip>
+<Tip>The `version` captured when you generate a test file is the version of TestDriver you used, and isn't used when running the test. This doesn't affect your ability to use newer versions of TestDriver on existing test files nor do these need to be updated when migrating to a new version.</Tip>
 
-### Modify the Test Steps
+### Modify the test 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.
 
-#### Example Edits:
+#### Example edits:
 - **Add a Wait Command**:
   ```yaml
   - command: wait
@@ -66,13 +70,13 @@ You can add, edit, or remove steps as needed. Each step contains:
     text: booking.com
   ```
 
-### Validate the YAML Syntax
+### Validate the YAML syntax
 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.
 
-### Test the Changes
+### Test the changes
 Run the updated test to verify it works as expected:
 ```bash
 testdriverai run path/to/test.yaml

package/docs/getting-started/generating.mdx

@@ -1,13 +1,13 @@
 ---
 title: "Self-Driving Tests"
 sidebarTitle: "Self-Driving Tests"
-description: "Generate test plans and integrate them into your testing workflow."
+description: "Generate test files and integrate them into your testing workflow."
 icon: "steering-wheel"
 ---
 
 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.
 
-# Launch TestDriver in Interactive Mode
+# Launch TestDriver in interactive mode
 
 Launch `testdriverai` in interactive mode with the following command:
 
@@ -61,7 +61,7 @@ steps:
   - prompt: Assert that there are issues during checkout and an error is displayed.
 ```
 
-# Generate Regression Tests from Exploratory Tests
+# Generate regression tests from exploratory tests
 
 Now it's time to generate the regression test.
 
@@ -80,11 +80,10 @@ No commands found, running exploratory
 
 When using the `--save` command, TestDriver appends any generated commands to the test file.
 
-So as your test run, TestDriver will append successful commands to the yaml file and save it.
+So as your test run, TestDriver will append successful commands to the YAML file and save it.
 
 ```yaml
 version: 5.3.11
-session: 6801430b5f2c252a8f4bed60
 steps:
   - prompt: Focus the browser window.
     commands: