testdriverai 6.0.23 → 6.0.24-canary.fffd04a.0

package/docs/action/setup.mdx

@@ -1,120 +0,0 @@
----
-title: "CI Setup Guide"
-sidebarTitle: "CI Setup"
-description: "Learn how to set up and configure TestDriver CLI for automated cloud-based testing in your CI workflows."
-icon: "square-terminal"
----
-
-## Overview
-
-TestDriver enables cloud-based testing using TestDriver's infrastructure directly through the CLI. This guide will walk you through the steps to configure TestDriver for GitHub actions, but the principles apply to other CI/CD platforms as well.
-
----
-
-## Step 1: Get Your API key
-
-To execute TestDriver actions on our virtual machines, you'll need an API key. Follow these steps to retrieve and configure your API key:
-
-1. **Upgrade Your Account**: Ensure you have a paid TestDriver account.
-2. **Log In**: Go to the **Team Page** in your TestDriver dashboard.
-3. **Copy Your API Key**: Locate and copy your API key.
-4. **Add the API Key as a GitHub Secret**:
-
-- Navigate to your repository settings in GitHub.
-- Add a new secret named `TD_API_KEY` and paste your API key.
-
----
-
-## Step 2: Create your workflow
-
-Now it's time to create your first TestDriver workflow. Add the following configuration to `.github/workflows/testdriver.yaml`:
-
-```yaml
-name: TestDriver
-
-permissions:
-  actions: read
-  contents: read
-  statuses: write
-  pull-requests: write
-
-on:
-  pull_request: # Run on every pull request event
-  schedule:
-    - cron: "0 * * * *" # Run every hour
-  push:
-    branches:
-      - main # Run on merge to the main branch
-  workflow_dispatch: # Manual trigger
-
-jobs:
-  test:
-    name: "TestDriver"
-    runs-on: ubuntu-latest
-    steps:
-      - name: Checkout code
-        uses: actions/checkout@v4
-
-      - name: Run TestDriver tests
-        run: npx testdriverai@latset run testdriver/testdriver.yaml
-        env:
-          TD_API_KEY: ${{ secrets.TD_API_KEY }}
-          FORCE_COLOR: "3"
-```
-
-### Key points:
-
-- **Trigger Conditions**: The `on` section defines when the workflow runs (for example, pull requests, scheduled events, or manual triggers).
-- **API Key**: The `TD_API_KEY` environment variable uses the secret for authentication.
-- **Test Execution**: TestDriver is called directly with your test commands.
-
----
-
-## Step 3: Deploy the workflow
-
-Save the workflow file, create a new branch, and push it to your repository. Then, create a pull request to trigger the workflow.
-
-```bash
-git checkout -b testdriver
-git commit -am 'Add TestDriver workflow'
-git push origin testdriver
-gh pr create --web
-```
-
----
-
-## How it works
-
-1. **Trigger**: The GitHub workflow is triggered based on the conditions defined in the `on` section.
-2. **Code Checkout**: The current branch's code is checked out in the GitHub runner.
-3. **CLI Installation**: The TestDriver CLI is installed globally using npm.
-4. **Authentication**: The `TD_API_KEY` environment variable authenticates your account.
-5. **VM Setup**: An ephemeral virtual machine is spawned on TestDriver's infrastructure.
-6. **Code Cloning**: The current branch's code is cloned onto the VM.
-7. **Dashcam Recording**: Dashcam begins recording the test execution.
-8. **Test Execution**: The TestDriver CLI executes your commands on the cloud VM.
-9. **Test Summary**: TestDriver summarizes the test and sets the exit code based on the pass or fail state.
-10. **Cleanup**: The VM is destroyed, and all data is wiped.
-
----
-
-## Additional features
-
-- **Multiple Commands**: You can run multiple TestDriver commands in sequence within your workflow.
-- **Environment Variables**: Pass custom environment variables to your tests.
-- **Staging Workflows**: A common workflow involves waiting for staging to deploy before executing tests.
-
----
-
-## Output
-
-For details on interpreting the output of TestDriver, refer to the [CLI Output Documentation](../cli/overview).
-
----
-
-## Notes
-
-- TestDriver CLI provides a simple and direct way to run cloud-based testing in your CI/CD pipelines.
-- Ensure your API key is securely stored as a GitHub secret.
-- The CLI automatically handles authentication and cloud VM provisioning when the `TD_API_KEY` is provided.
-- For advanced workflows, consider using multiple TestDriver commands or custom environment variables.

package/docs/interactive/assert.mdx

@@ -1,65 +0,0 @@
----
-title: "/assert"
-sidebarTitle: "/assert"
-description: "Use the /assert command to ensure specific conditions are met in your tests."
-icon: "clipboard-check"
----
-
-# Command: `/assert`
-
-## Description
-
-The `/assert` command ensures that a specific condition is true within your test. This is useful for verifying that tasks were completed successfully, just as a user would observe.
-
-## Usage
-
-```bash
-/assert <criteria>
-```
-
-## Behavior
-
-- The `/assert` command generates an assertion based on the specified criteria.
-- TestDriver takes a screenshot and uses it to verify that the condition described in the `expect` field is true.
-- If the condition isn't met, the test will fail and exit immediately.
-
-## Example usage
-
-### Basic assertion
-
-```bash
-/assert No error message is displayed
-```
-
-This generates the following command:
-
-```yaml
-- command: assert
-  expect: There is no error message
-```
-
-### Asynchronous assertion
-
-To speed up tests, use `async: true` to allow the test to continue without waiting for the assertion to pass:
-
-```yaml
-- command: assert
-  expect: There is no error message
-  async: true
-```
-
-## Protips
-
-- Use assertions sparingly to avoid slowing down your tests.
-- Combine `async: true` with assertions to improve test performance while still validating critical conditions.
-- Ensure the `expect` field clearly describes the condition to avoid ambiguity.
-
-## Gotchas
-
-- If the condition in `expect` isn't met, the test will fail and exit immediately.
-- Overusing assertions can make tests slower and harder to maintain.
-
-## Notes
-
-- The `/assert` command is ideal for validating key checkpoints in your test workflow.
-- Use this command to ensure that critical tasks, such as error-free execution or successful navigation, are completed as expected.

package/docs/interactive/dry.mdx

@@ -1,58 +0,0 @@
----
-title: "/dry"
-sidebarTitle: "/dry"
-description: "See and write a test file without running the commands."
-icon: "forward-step"
----
-
-## Description
-
-The `/dry` command is used to create a test file and write to a specified file. This command won't run steps it creates. It's a **dry** run.
-
-## Usage
-
-```bash
-/dry <file>
-```
-
-## Example usage
-
-```bash
-npx testdriverai@latest <filename.yaml>
-> /dry click the 'log in' button
-```
-
-This command generates the steps to `click the 'log in' button` with an explanation and adds them to the current test file, without executing any command.
-
-## Behavior
-
-- TestDriver will create steps for the test file, writing them in the file.
-- TestDriver will also show the reasoning and test steps in the CLI:
-
-```bash
-thinking...
-
-    To click the 'log in' button, we need to identify and
-    click on the text "Log in" visible in the screenshot.
-    Here's how to accomplish this:
-
-    commands:
-      - command: hover-text
-        text: Log in
-        description: log in button in the code editor
-        action: click
-
-    ### Explanation:
-
-    1. Click the 'Log in' Button: We use hover-text to locate and click on the "Log in" text visible in the code editor. This ensures the button is activated.
-```
-
-## Protips
-
-- Ensure you run the `testdriverai` command with a valid file path before using `/dry`.
-- Use descriptive filenames for your test files to make them easier to identify.
-- Combine `/dry` with `/undo` to write test files without executing them.
-
-## Notes
-
-- The `/dry` command is ideal for writing out a series of steps before executing.

package/docs/interactive/generate.mdx

@@ -1,55 +0,0 @@
----
-title: "/generate"
-sidebarTitle: "/generate"
-description: "Use the /generate command to create exploratory test cases automatically."
-icon: "wand-sparkles"
----
-
-# Command: `/generate`
-
-## Description
-
-The `/generate` command is an experimental feature that instructs TestDriver to create its own exploratory prompts. This command is used in the "Generate a Test Suite" demo and is designed to help automate the creation of exploratory test cases.
-
-## Usage
-
-```bash
-/generate
-```
-
-## Behavior
-
-- The `/generate` command analyzes the display and generates exploratory prompts for testing.
-- Each exploratory test is saved as a simple Markdown file containing a list of steps.
-- TestDriver generates 10 Markdown files every time the `/generate` command is called.
-- The generated files are stored in the `./testdriver/generate/*.md` directory.
-
-## Example output
-
-Here's an example of a generated test file (`test-search-function.md`):
-
-```markdown
-1. Click on the search icon.
-2. Type "real-time chat" into the search bar.
-3. Assert that search results are relevant and displayed.
-```
-
-## Protips
-
-- Use `/generate` to quickly create exploratory tests for regression testing or feature validation.
-- Combine `/generate` with the GitHub Action to generate and run regression tests in parallel.
-- Review the generated Markdown files and convert them into YAML test scripts for reuse.
-
-## Gotchas
-
-- The `/generate` command is experimental and may not always produce perfect test cases. Review and refine the generated tests as needed.
-- Ensure the `./testdriver/generate/` directory exists and has write permissions.
-
-## Notes
-
-- The `/generate` command is ideal for automating the creation of exploratory test cases and generating regression tests.
-- Generated tests can be merged into a regression test suite for continuous testing and validation.
-
-```
-
-```

package/docs/interactive/undo.mdx

@@ -1,58 +0,0 @@
----
-title: "/undo"
-sidebarTitle: "/undo"
-description: "Remove the last generated command or step from the current test script."
-icon: "arrow-rotate-left"
----
-
-## Description
-
-The `/undo` command removes the last generated command or step from the current test script. This is useful for quickly correcting mistakes or removing unintended actions during an interactive session.
-
-## Usage
-
-```bash
-/undo
-```
-
-## Behavior
-
-- The `/undo` command removes the most recently added command or step from the test script.
-- You can call `/undo` multiple times to remove multiple commands or steps.
-
-## Example usage
-
-### Before `/undo`
-
-```yaml
-- step:
-    - command: scroll-until-text
-      text: Add to cart
-- step:
-    - command: hover-text
-      text: Add to cart
-      action: click
-```
-
-### After `/undo`
-
-```yaml
-- step:
-    - command: scroll-until-text
-      text: Add to cart
-```
-
-## Protips
-
-- Use `/undo` immediately after generating a command to quickly fix mistakes or refine your test script.
-- Combine `/undo` with `/save` to iteratively build and refine your test scripts.
-
-## Gotchas
-
-- The `/undo` command only removes the last generated command or step. If you need to undo multiple actions, call `/undo` repeatedly.
-- Once a session is closed, you can't undo previously saved commands.
-
-## Notes
-
-- The `/undo` command is ideal for interactive sessions where you are experimenting with test generation.
-- This command helps maintain a clean and accurate test script by allowing quick corrections.

package/docs/snippets/comments.mdx

@@ -1 +0,0 @@
-<div id="discourse-comments"></div>

package/docs/snippets/tests/prompt-replay.mdx

@@ -1,5 +0,0 @@
-<iframe
-  src="https://app.dashcam.io/replay/6866b262409e098717b0151f?share=dZG9aaVeNpIcA1CzcotuQ&embed=true&timestamp=90000&playbackRate=5"
-  width="100%"
-  height="300"
-/>

package/docs/snippets/tests/prompt-yaml.mdx

@@ -1,10 +0,0 @@
-```yaml
-version: 5.7.7
-session: 682f5aab811bd5a322c0e5a1
-steps:
-  - prompt: enter a valid username, password, and sign in
-  - prompt: assert
-    commands:
-      - command: assert
-        expect: the testdriver sandbox is visible
-```

package/docs/snippets/yml-warning.mdx

@@ -1,4 +0,0 @@
-<Warning>
-  TestDriver v5 uses the `.yaml` file extension for all test files. This is a
-  breaking change from v4 which uses the `.yml` extension!
-</Warning>