testdriverai 5.2.2 → 5.3.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.github/workflows/test-install.yml +1 -1
- package/README.md +5 -11
- package/agent.js +135 -99
- package/docs/30x30.mdx +84 -0
- package/docs/action/browser.mdx +129 -0
- package/docs/action/os.mdx +157 -0
- package/docs/action/output.mdx +98 -0
- package/docs/action/performance.mdx +71 -0
- package/docs/action/prerun.mdx +80 -0
- package/docs/action/secrets.mdx +103 -0
- package/docs/action/setup.mdx +115 -0
- package/docs/bugs/jira.mdx +208 -0
- package/docs/cli/overview.mdx +65 -0
- package/docs/commands/assert.mdx +31 -0
- package/docs/commands/exec.mdx +42 -0
- package/docs/commands/focus-application.mdx +29 -0
- package/docs/commands/hover-image.mdx +32 -0
- package/docs/commands/hover-text.mdx +37 -0
- package/docs/commands/if.mdx +43 -0
- package/docs/commands/match-image.mdx +41 -0
- package/docs/commands/press-keys.mdx +30 -0
- package/docs/commands/run.mdx +30 -0
- package/docs/commands/scroll-until-image.mdx +33 -0
- package/docs/commands/scroll-until-text.mdx +37 -0
- package/docs/commands/scroll.mdx +33 -0
- package/docs/commands/type.mdx +29 -0
- package/docs/commands/wait-for-image.mdx +31 -0
- package/docs/commands/wait-for-text.mdx +35 -0
- package/docs/commands/wait.mdx +30 -0
- package/docs/docs.json +226 -0
- package/docs/exporting/playwright.mdx +159 -0
- package/docs/features/auto-healing.mdx +124 -0
- package/docs/features/cross-platform.mdx +106 -0
- package/docs/features/generation.mdx +180 -0
- package/docs/features/github.mdx +161 -0
- package/docs/features/parallel-testing.mdx +130 -0
- package/docs/features/reusable-snippets.mdx +124 -0
- package/docs/features/selectorless.mdx +62 -0
- package/docs/features/visual-assertions.mdx +123 -0
- package/docs/getting-started/ci.mdx +196 -0
- package/docs/getting-started/generating.mdx +210 -0
- package/docs/getting-started/running.mdx +67 -0
- package/docs/getting-started/setup.mdx +133 -0
- package/docs/getting-started/writing.mdx +99 -0
- package/docs/guide/assertions.mdx +195 -0
- package/docs/guide/authentication.mdx +150 -0
- package/docs/guide/code.mdx +169 -0
- package/docs/guide/locating.mdx +136 -0
- package/docs/guide/setup-teardown.mdx +161 -0
- package/docs/guide/variables.mdx +218 -0
- package/docs/guide/waiting.mdx +199 -0
- package/docs/importing/csv.mdx +196 -0
- package/docs/importing/gherkin.mdx +142 -0
- package/docs/importing/jira.mdx +172 -0
- package/docs/importing/testrail.mdx +161 -0
- package/docs/integrations/electron.mdx +152 -0
- package/docs/integrations/netlify.mdx +98 -0
- package/docs/integrations/vercel.mdx +177 -0
- package/docs/interactive/assert.mdx +51 -0
- package/docs/interactive/generate.mdx +41 -0
- package/docs/interactive/run.mdx +36 -0
- package/docs/interactive/save.mdx +53 -0
- package/docs/interactive/undo.mdx +47 -0
- package/docs/issues.mdx +9 -0
- package/docs/overview/comparison.mdx +82 -0
- package/docs/overview/faq.mdx +122 -0
- package/docs/overview/quickstart.mdx +66 -0
- package/docs/overview/what-is-testdriver.mdx +73 -0
- package/docs/quickstart.mdx +66 -0
- package/docs/reference/commands/scroll.mdx +0 -0
- package/docs/reference/interactive/assert.mdx +0 -0
- package/docs/security/action.mdx +62 -0
- package/docs/security/agent.mdx +62 -0
- package/docs/security/dashboard.mdx +0 -0
- package/docs/security/platform.mdx +54 -0
- package/docs/tutorials/advanced-test.mdx +79 -0
- package/docs/tutorials/basic-test.mdx +41 -0
- package/electron/icon.png +0 -0
- package/electron/overlay.html +7 -3
- package/electron/overlay.js +75 -15
- package/electron/tray-buffered.png +0 -0
- package/electron/tray.png +0 -0
- package/index.js +75 -34
- package/lib/commander.js +22 -1
- package/lib/commands.js +87 -19
- package/lib/config.js +10 -1
- package/lib/focus-application.js +30 -23
- package/lib/generator.js +58 -7
- package/lib/init.js +48 -19
- package/lib/ipc.js +50 -0
- package/lib/logger.js +19 -6
- package/lib/overlay.js +82 -36
- package/lib/parser.js +9 -7
- package/lib/resources/prerun.yaml +17 -0
- package/lib/sandbox.js +2 -3
- package/lib/sdk.js +0 -2
- package/lib/session.js +3 -1
- package/lib/speak.js +0 -2
- package/lib/subimage/opencv.js +0 -4
- package/lib/system.js +56 -39
- package/lib/upload-secrets.js +65 -0
- package/lib/validation.js +175 -0
- package/package.json +2 -1
- package/postinstall.js +0 -24
- package/lib/websockets.js +0 -85
- package/test.md +0 -8
- package/test.yml +0 -18
|
@@ -0,0 +1,122 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "FAQ"
|
|
3
|
+
sidebarTitle: "FAQ"
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
|
|
7
|
+
## What is TestDriver?
|
|
8
|
+
TestDriver is an AI-powered testing platform that simulates user interactions to automate end-to-end testing for web, desktop, and mobile applications.
|
|
9
|
+
|
|
10
|
+
## How does TestDriver work?
|
|
11
|
+
It interprets high-level prompts, interacts with interfaces like a user would, and verifies expected outcomes using visual assertions.
|
|
12
|
+
|
|
13
|
+
## What platforms does TestDriver support?
|
|
14
|
+
TestDriver supports Windows, Mac, Linux, desktop apps, chrome extensions, web browsers, and mobile interfaces (via emulator or device farm).
|
|
15
|
+
|
|
16
|
+
## Can it be used for exploratory testing?
|
|
17
|
+
Yes. TestDriver can autonomously navigate the application to generate new test cases.
|
|
18
|
+
|
|
19
|
+
## Can it test desktop applications?
|
|
20
|
+
Yes. It supports testing native desktop applications by simulating mouse and keyboard input and identifying UI elements.
|
|
21
|
+
|
|
22
|
+
## Can it test mobile apps?
|
|
23
|
+
Yes, via mobile emulators or integration with device farms.
|
|
24
|
+
|
|
25
|
+
## Can TestDriver generate tests automatically?
|
|
26
|
+
Yes, it explores the app and creates test cases based on UI flows and user interactions.
|
|
27
|
+
|
|
28
|
+
## Can I create tests from natural language prompts?
|
|
29
|
+
Yes. You can write high-level instructions in plain language, and TestDriver will interpret and build tests from them.
|
|
30
|
+
|
|
31
|
+
## Can it generate tests from user stories or documentation?
|
|
32
|
+
Yes. It can use minimal descriptions to produce complete test cases.
|
|
33
|
+
|
|
34
|
+
## Can it turn recorded user sessions into tests?
|
|
35
|
+
No, an important part of AI-native testing is the intent behind the actions. TestDriver focuses on understanding user goals rather than just recording actions.
|
|
36
|
+
|
|
37
|
+
## What happens when the UI changes?
|
|
38
|
+
TestDriver adapts using AI—if a button or label changes, it can often infer the correct action without breaking.
|
|
39
|
+
|
|
40
|
+
## Do I need to rewrite tests often?
|
|
41
|
+
No. TestDriver reduces maintenance by handling common UI changes automatically.
|
|
42
|
+
|
|
43
|
+
## How does it handle flaky tests?
|
|
44
|
+
TestDriver Enterprise Dashboards provide insights into test stability, helping you identify flaky tests and their causes.
|
|
45
|
+
|
|
46
|
+
## How are tests updated over time?
|
|
47
|
+
TestDriver will open pull requests in your repository with updated tests when it detects changes in the UI or application behavior. You can also regenerate tests using the original prompts manually.
|
|
48
|
+
|
|
49
|
+
## How does TestDriver report test failures?
|
|
50
|
+
It provides detailed logs, screenshots, console output, and visual diffs.
|
|
51
|
+
|
|
52
|
+
## What happens when a test fails?
|
|
53
|
+
It stops execution, flags the failing step, and provides context for debugging.
|
|
54
|
+
|
|
55
|
+
## Can I view why a test failed?
|
|
56
|
+
Yes. You can view step-by-step logs, network traffic, DOM state, and video playback of the test run.
|
|
57
|
+
|
|
58
|
+
## Can it automatically retry failed actions?
|
|
59
|
+
Yes. You can configure retry behavior for individual steps or full tests.
|
|
60
|
+
|
|
61
|
+
## Can I run tests in parallel?
|
|
62
|
+
Yes. TestDriver supports parallel execution using multiple VMs or containers.
|
|
63
|
+
|
|
64
|
+
## Can I track performance metrics during testing?
|
|
65
|
+
Yes. It can log CPU, memory, load times, and frame rates to help catch performance regressions.
|
|
66
|
+
|
|
67
|
+
## Can it validate non-deterministic output?
|
|
68
|
+
Yes. It uses AI assertions to verify outcomes even when outputs vary (e.g., generated text or dynamic UIs).
|
|
69
|
+
|
|
70
|
+
## Can it test workflows with variable inputs?
|
|
71
|
+
Yes. It supports data-driven tests using parameterized inputs.
|
|
72
|
+
|
|
73
|
+
## Can it test file uploads and downloads?
|
|
74
|
+
Yes. TestDriver can interact with file pickers and validate uploaded/downloaded content.
|
|
75
|
+
|
|
76
|
+
## Can it generate tests for PDFs or document output?
|
|
77
|
+
Yes. It can open and verify generated files for expected text or formatting.
|
|
78
|
+
|
|
79
|
+
## Can I trigger tests based on pull requests or merges?
|
|
80
|
+
Yes. You can integrate TestDriver with your CI to trigger runs via GitHub Actions or other CI/CD tools.
|
|
81
|
+
|
|
82
|
+
## Does it integrate with CI/CD tools?
|
|
83
|
+
Yes. TestDriver integrates with pipelines like GitHub Actions, GitLab CI, and CircleCI.
|
|
84
|
+
|
|
85
|
+
## Can I integrate TestDriver with Jira, Slack, etc.?
|
|
86
|
+
Yes. You can receive alerts and sync test results with third-party tools via API/webhooks.
|
|
87
|
+
|
|
88
|
+
## Does it support cloud and local environments?
|
|
89
|
+
Yes. You can run tests locally or in the cloud using ephemeral VMs for clean state testing.
|
|
90
|
+
|
|
91
|
+
## Does it work with existing test frameworks?
|
|
92
|
+
It can complement or convert some existing test cases into its format, though full conversion depends on compatibility.
|
|
93
|
+
|
|
94
|
+
## How does TestDriver measure test coverage?
|
|
95
|
+
It tracks UI paths, element interaction frequency, and application state changes to infer coverage.
|
|
96
|
+
|
|
97
|
+
## Can it suggest missing test scenarios?
|
|
98
|
+
Yes. Based on interaction patterns and user behavior, it can propose additional test cases.
|
|
99
|
+
|
|
100
|
+
## Can it analyze test stability over time?
|
|
101
|
+
Yes. You can view trends in pass/fail rates and test execution consistency.
|
|
102
|
+
|
|
103
|
+
## Is it safe to test sensitive data?
|
|
104
|
+
Yes. TestDriver supports variable obfuscation, secure containers, and test data isolation.
|
|
105
|
+
|
|
106
|
+
## Can I avoid using production data in tests?
|
|
107
|
+
Yes. You can configure mock data, sanitize logs, and use test-specific environments.
|
|
108
|
+
|
|
109
|
+
## How does the AI understand what to test?
|
|
110
|
+
It uses language models to interpret your goals, element names, and interface cues to perform tasks.
|
|
111
|
+
|
|
112
|
+
## Can I adjust how the AI interprets my prompt?
|
|
113
|
+
Yes. You can rewrite prompts, add constraints, or review and tweak auto-generated steps.
|
|
114
|
+
|
|
115
|
+
## Can I see what the AI is doing behind the scenes?
|
|
116
|
+
Yes. You can inspect the resolved steps, see element matches, and adjust test flows before execution.
|
|
117
|
+
|
|
118
|
+
## Can I use TestDriver to test new features?
|
|
119
|
+
Yes. It’s great for validating changes, ensuring no regressions, and verifying rollout configurations.
|
|
120
|
+
|
|
121
|
+
## Can it test seasonal or time-based behaviors?
|
|
122
|
+
Yes. You can schedule tests or run them under specific date/time settings to verify time-sensitive logic.
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Quickstart"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
<Steps>
|
|
6
|
+
|
|
7
|
+
<Step title="Install TestDriver">
|
|
8
|
+
Install the TestDriver CLI globally:
|
|
9
|
+
```bash
|
|
10
|
+
npm install -g testdriverai@beta
|
|
11
|
+
```
|
|
12
|
+
</Step>
|
|
13
|
+
|
|
14
|
+
<Step title="Initialize Your Project">
|
|
15
|
+
Set up your project with:
|
|
16
|
+
```bash
|
|
17
|
+
testdriverai init
|
|
18
|
+
```
|
|
19
|
+
This creates a `.env` file and sample workflow files.
|
|
20
|
+
</Step>
|
|
21
|
+
|
|
22
|
+
<Step title="Run TestDriver in Interactive Mode">
|
|
23
|
+
Start TestDriver in interactive mode to create and refine tests dynamically:
|
|
24
|
+
```bash
|
|
25
|
+
testdriverai
|
|
26
|
+
```
|
|
27
|
+
Once started, you can use commands like `/try`, `/undo`, and `/save` to interactively build and test your flows.
|
|
28
|
+
</Step>
|
|
29
|
+
|
|
30
|
+
<Step title="Define Your Test Steps">
|
|
31
|
+
Use natural language to describe what you want to test. For example:
|
|
32
|
+
```
|
|
33
|
+
> Open Google Chrome and search for "testdriverai"
|
|
34
|
+
```
|
|
35
|
+
TestDriver will generate steps like:
|
|
36
|
+
```yaml
|
|
37
|
+
- command: focus-application
|
|
38
|
+
name: Google Chrome
|
|
39
|
+
- command: hover-text
|
|
40
|
+
text: Search Google or type a URL
|
|
41
|
+
description: main search bar
|
|
42
|
+
action: click
|
|
43
|
+
- command: type
|
|
44
|
+
text: testdriverai
|
|
45
|
+
- command: press-keys
|
|
46
|
+
keys: [enter]
|
|
47
|
+
```
|
|
48
|
+
</Step>
|
|
49
|
+
|
|
50
|
+
<Step title="Refine and Save Your Test">
|
|
51
|
+
- Use `/undo` to remove the last step if needed.
|
|
52
|
+
- Save your test with `/save` to generate a reusable YAML file.
|
|
53
|
+
</Step>
|
|
54
|
+
|
|
55
|
+
<Step title="Run Saved Tests">
|
|
56
|
+
Once saved, you can run your test file anytime:
|
|
57
|
+
```bash
|
|
58
|
+
testdriverai run path/to/test.yml
|
|
59
|
+
```
|
|
60
|
+
</Step>
|
|
61
|
+
|
|
62
|
+
</Steps>
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
**Pro Tip:** Always start with interactive mode (`testdriverai`) to explore and refine your tests before saving them. It’s faster and more intuitive!
|
|
@@ -0,0 +1,73 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "What is TestDriver?"
|
|
3
|
+
description: "TestDriver is a computer-use agent for QA testing of user interfaces."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
TestDriver uses AI vision and keyboard and mouse control to automate end-to-end testing. TestDriver is `selectorless` meaning it is not aware of the underlying code structure.
|
|
7
|
+
|
|
8
|
+
- **Easier set up:** No need to craft complex selectors
|
|
9
|
+
- **Less Maintenance:** Tests don't break when code changes
|
|
10
|
+
- **More Power:** TestDriver can test any application and control any OS setting
|
|
11
|
+
|
|
12
|
+
TestDriver is different from other computer-use agents in that it produces a `YAML` test script that increases the speed and repeatability of testing.
|
|
13
|
+
|
|
14
|
+
### Selectorless Testing
|
|
15
|
+
|
|
16
|
+
Unlike traditional frameworks (e.g., Selenium, Playwright), TestDriver doesn’t rely on CSS selectors or static analysis. Instead, tests are described in plain English, such as:
|
|
17
|
+
|
|
18
|
+
```
|
|
19
|
+
> Open Google Chrome and search for "testdriver"
|
|
20
|
+
```
|
|
21
|
+
|
|
22
|
+
This means that you can write tests without worrying about the underlying code structure:
|
|
23
|
+
|
|
24
|
+
- Test any user flow on any website in any browser
|
|
25
|
+
- Clone, build, and test any desktop app
|
|
26
|
+
- Render multiple browser windows and popups like 3rd party auth
|
|
27
|
+
- Test `<canvas>`, `<iframe>`, and `<video>` tags with ease
|
|
28
|
+
- Use file selectors to upload files to the browser
|
|
29
|
+
- Resize the browser
|
|
30
|
+
- Test chrome extensions
|
|
31
|
+
- Test integrations between applications
|
|
32
|
+
|
|
33
|
+
### The problem with current approach to end-to-end testing
|
|
34
|
+
|
|
35
|
+
End-to-end is commonly described as the most expensive and time-consuming test method. Right now we write end-to-end tests using complex selectors that are tightly coupled with the code.
|
|
36
|
+
|
|
37
|
+
```js
|
|
38
|
+
const e = await page.$('div[class="product-card"] >> text="Add to Cart" >> nth=2');
|
|
39
|
+
```
|
|
40
|
+
|
|
41
|
+
This tight coupling means developers need to spend time to understand the codebase and maintain the tests every time the code changes. And code is always changing!
|
|
42
|
+
|
|
43
|
+
### End-to-end is about users, not code
|
|
44
|
+
|
|
45
|
+
In end-to-end testing the business priority is usability. All that really matters is that the user can accomplish the goal.
|
|
46
|
+
|
|
47
|
+
TestDriver uses human language to define test requirements. Then our simulated software tester figures out how to accomplish those goals.
|
|
48
|
+
|
|
49
|
+
Old and Busted (Selectors) | New Hotness (TestDriver)
|
|
50
|
+
|:----------------------|:-------------------|
|
|
51
|
+
```div[class="product-card"] >> text="Add to Cart" >> nth=2``` | buy the 2nd product
|
|
52
|
+
|
|
53
|
+
These high level instructions are easier to create and maintain because they are loosely coupled from the codebase. We're describing a high level goal, not a low level interaction.
|
|
54
|
+
|
|
55
|
+
The tests will still continue to work even when the junior developer changes .product-card to .product.card or the designers change Add to Cart to Buy Now . The concepts remain the same so the AI will adapt.
|
|
56
|
+
|
|
57
|
+
## How exactly does this work?
|
|
58
|
+
|
|
59
|
+
TestDriver uses a combination of reinforcement learning and computer vision. The context from successful text executions inform future executions. Here's an example of the context our model considers when locating a text match:
|
|
60
|
+
|
|
61
|
+
Context| What is it? | Touchpoint
|
|
62
|
+
|:----------|:------------------|:----------------|
|
|
63
|
+
Prompt | Desired outcome | User Input
|
|
64
|
+
Screenshot | Image of computer desktop | Runtime
|
|
65
|
+
OCR | All possible text found on screen Runtime
|
|
66
|
+
Text Similarity | Closely matching text | Runtime
|
|
67
|
+
Redraw | Visual difference between previous and current desktop screenshots | Runtime
|
|
68
|
+
Network | The current network activity compared to a baseline | Runtime
|
|
69
|
+
Execution History | Previous test steps | Runtime
|
|
70
|
+
System Information | Platform, Display Size, etc | Runtime
|
|
71
|
+
Mouse Position | X, Y coordinates of mouse | Runtime
|
|
72
|
+
Description | An elaborate description of the target element including it's position and function | Past Execution
|
|
73
|
+
Text | The exact text value clicked | Past Execution
|
|
@@ -0,0 +1,66 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Quickstart"
|
|
3
|
+
---
|
|
4
|
+
|
|
5
|
+
<Steps>
|
|
6
|
+
|
|
7
|
+
<Step title="Install TestDriver">
|
|
8
|
+
Install the TestDriver CLI globally:
|
|
9
|
+
```bash
|
|
10
|
+
npm install -g testdriverai@beta
|
|
11
|
+
```
|
|
12
|
+
</Step>
|
|
13
|
+
|
|
14
|
+
<Step title="Initialize Your Project">
|
|
15
|
+
Set up your project with:
|
|
16
|
+
```bash
|
|
17
|
+
testdriverai init
|
|
18
|
+
```
|
|
19
|
+
This creates a `.env` file and sample workflow files.
|
|
20
|
+
</Step>
|
|
21
|
+
|
|
22
|
+
<Step title="Run TestDriver in Interactive Mode">
|
|
23
|
+
Start TestDriver in interactive mode to create and refine tests dynamically:
|
|
24
|
+
```bash
|
|
25
|
+
testdriverai
|
|
26
|
+
```
|
|
27
|
+
Once started, you can use commands like `/try`, `/undo`, and `/save` to interactively build and test your flows.
|
|
28
|
+
</Step>
|
|
29
|
+
|
|
30
|
+
<Step title="Define Your Test Steps">
|
|
31
|
+
Use natural language to describe what you want to test. For example:
|
|
32
|
+
```
|
|
33
|
+
> Open Google Chrome and search for "testdriverai"
|
|
34
|
+
```
|
|
35
|
+
TestDriver will generate steps like:
|
|
36
|
+
```yaml
|
|
37
|
+
- command: focus-application
|
|
38
|
+
name: Google Chrome
|
|
39
|
+
- command: hover-text
|
|
40
|
+
text: Search Google or type a URL
|
|
41
|
+
description: main search bar
|
|
42
|
+
action: click
|
|
43
|
+
- command: type
|
|
44
|
+
text: testdriverai
|
|
45
|
+
- command: press-keys
|
|
46
|
+
keys: [enter]
|
|
47
|
+
```
|
|
48
|
+
</Step>
|
|
49
|
+
|
|
50
|
+
<Step title="Refine and Save Your Test">
|
|
51
|
+
- Use `/undo` to remove the last step if needed.
|
|
52
|
+
- Save your test with `/save` to generate a reusable YAML file.
|
|
53
|
+
</Step>
|
|
54
|
+
|
|
55
|
+
<Step title="Run Saved Tests">
|
|
56
|
+
Once saved, you can run your test file anytime:
|
|
57
|
+
```bash
|
|
58
|
+
testdriverai run path/to/test.yml
|
|
59
|
+
```
|
|
60
|
+
</Step>
|
|
61
|
+
|
|
62
|
+
</Steps>
|
|
63
|
+
|
|
64
|
+
---
|
|
65
|
+
|
|
66
|
+
**Pro Tip:** Always start with interactive mode (`testdriverai`) to explore and refine your tests before saving them. It’s faster and more intuitive!
|
|
File without changes
|
|
File without changes
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Security Features of the TestDriver Action"
|
|
3
|
+
sidebarTitle: "GitHub Action"
|
|
4
|
+
description: "Understand the ephemeral VM runners, secrets handling, and environment-specific security for the TestDriver Action."
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# TestDriver Action Security
|
|
8
|
+
|
|
9
|
+
## Open Source
|
|
10
|
+
The TestDriver Action is open source, and its source code is available for review. You can find the repository here:
|
|
11
|
+
|
|
12
|
+
[GitHub - testdriverai/action](https://github.com/testdriverai/action)
|
|
13
|
+
|
|
14
|
+
## Ephemeral Virtual Machine Runners
|
|
15
|
+
TestDriver tests are executed on private virtual machines (VMs) managed by Amazon EC2. These VMs are ephemeral, meaning they only exist for the duration of the test execution. Once the test is complete:
|
|
16
|
+
- The VM is destroyed.
|
|
17
|
+
- The hard disk is wiped to ensure no residual data remains.
|
|
18
|
+
|
|
19
|
+
## Secrets
|
|
20
|
+
To securely manage private information, we recommend storing sensitive data as secrets in your GitHub repository. Learn more about [storing secrets in GitHub](https://docs.github.com/en/actions/security-guides/encrypted-secrets).
|
|
21
|
+
|
|
22
|
+
### Handling Secrets
|
|
23
|
+
- **Prerun Scripts**: Any secrets supplied within prerun scripts or prompts are transmitted over SSL to the TestDriver API. Prerun scripts are **not persisted**.
|
|
24
|
+
- **Agent Prompts**: Secrets supplied to agent prompts are persisted (see [Agent Security](../agent)).
|
|
25
|
+
- **Secure Workflows**: If your workflow requires secret sharing and you encounter issues, please contact us for assistance.
|
|
26
|
+
|
|
27
|
+
### Common Use Case
|
|
28
|
+
A common workflow involves using prerun scripts to securely access a private staging website via basic authentication. This allows you to log into staging environments without persisting sensitive data on TestDriver servers.
|
|
29
|
+
|
|
30
|
+
## Environment-Specific Security
|
|
31
|
+
|
|
32
|
+
### Production
|
|
33
|
+
Testing production environments is the simplest and most secure starting point.
|
|
34
|
+
- Production testing does not require any private information from your team.
|
|
35
|
+
- Simply provide the tests to TestDriver and point them toward publicly available endpoints.
|
|
36
|
+
- TestDriver does not need access to any private or sensitive information for production testing.
|
|
37
|
+
|
|
38
|
+
### Staging
|
|
39
|
+
Testing staging environments may require secure information, such as credentials or tokens.
|
|
40
|
+
- Use GitHub secrets to securely store and manage this information.
|
|
41
|
+
- Refer to the **Secrets** section above for guidance on securely implementing tests for staging environments.
|
|
42
|
+
|
|
43
|
+
### Development
|
|
44
|
+
TestDriver can clone feature branches and build code on its virtual machines using workflows similar to GitHub Actions.
|
|
45
|
+
|
|
46
|
+
#### GitHub Token for Development
|
|
47
|
+
To test development branches of private codebases, you must supply a GitHub personal access token within the GitHub Action. This token is used to:
|
|
48
|
+
- Clone the codebase onto the VM.
|
|
49
|
+
- Build and test the code in an isolated environment.
|
|
50
|
+
|
|
51
|
+
Example configuration:
|
|
52
|
+
```yaml
|
|
53
|
+
env:
|
|
54
|
+
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
|
|
55
|
+
```
|
|
56
|
+
- The token is transmitted over SSL and is **not persisted**.
|
|
57
|
+
- Learn more about managing the privacy of GitHub access tokens [here](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token).
|
|
58
|
+
|
|
59
|
+
## Notes
|
|
60
|
+
- TestDriver's ephemeral VMs ensure that no data persists beyond the test execution.
|
|
61
|
+
- For maximum security, always use GitHub secrets to manage sensitive information.
|
|
62
|
+
- If you have specific security concerns or requirements, feel free to contact us for support.
|
|
@@ -0,0 +1,62 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Security Features of the TestDriver Agent"
|
|
3
|
+
sidebarTitle: "TestDriver Agent "
|
|
4
|
+
description: "Explore the data collected, persistence, and privacy practices of the TestDriver Agent."
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# TestDriver Agent Security
|
|
8
|
+
|
|
9
|
+
## Source
|
|
10
|
+
The TestDriver Agent is open-source and available on NPM. You can browse the source code to see all the data collected and understand how everything works.
|
|
11
|
+
|
|
12
|
+
## API
|
|
13
|
+
The TestDriver Agent does not contain any AI models within it. Instead, it uploads desktop context to the TestDriver API, which uses that context to make decisions about what actions to perform.
|
|
14
|
+
|
|
15
|
+
The TestDriver API leverages OpenAI models behind the scenes. For more information about OpenAI and its privacy practices, visit their [privacy center](https://openai.com/privacy).
|
|
16
|
+
|
|
17
|
+
## Desktop Context Collected
|
|
18
|
+
During execution, the TestDriver Agent uploads the following information to the API:
|
|
19
|
+
|
|
20
|
+
- **User Input Prompts**: The commands and prompts you provide to TestDriver.
|
|
21
|
+
- **Active Window and Other Windows**: Information about the active window and other open windows, including application and window titles.
|
|
22
|
+
- **System Information**: Details about the computer system running TestDriver.
|
|
23
|
+
- **Mouse Position**: The current position of the mouse pointer.
|
|
24
|
+
- **Desktop Screenshots**: Screenshots of the primary display.
|
|
25
|
+
|
|
26
|
+
### Data Persistence
|
|
27
|
+
- **Desktop Context**: All collected desktop context, except for screenshots, is persisted in the TestDriver database.
|
|
28
|
+
- **Desktop Screenshots**: Screenshots are uploaded to the server for processing but are not stored in the database.
|
|
29
|
+
|
|
30
|
+
### Desktop Screenshots
|
|
31
|
+
TestDriver frequently captures screenshots of the desktop to provide the AI with decision-making context. These screenshots are uploaded to the API but are not persisted in the database.
|
|
32
|
+
|
|
33
|
+
- **Primary Display Only**: Screenshots are limited to the primary display.
|
|
34
|
+
- **Privacy Recommendation**: For complete privacy, it is recommended to run TestDriver within a virtual machine on your desktop.
|
|
35
|
+
|
|
36
|
+
**Important**: TestDriver cannot operate without visual context. Do not install TestDriver if you are uncomfortable with capturing images of the desktop.
|
|
37
|
+
|
|
38
|
+
## Collected Data Details
|
|
39
|
+
|
|
40
|
+
### Active Window
|
|
41
|
+
Information about the open windows on the desktop is reported using the `active-window` module. This includes details such as the application name and window titles.
|
|
42
|
+
|
|
43
|
+
### System Information
|
|
44
|
+
System details, such as operating system, CPU, and memory, are reported using the `systeminformation` module.
|
|
45
|
+
|
|
46
|
+
### User Prompts
|
|
47
|
+
The prompts you input into TestDriver are uploaded to the API and stored in a database. This data is used to provide the AI with a history of context for better decision-making.
|
|
48
|
+
|
|
49
|
+
## Additional Analytics
|
|
50
|
+
When running `testdriver init`, you will be asked if you would like to share additional analytics. Sharing usage analytics is **opt-in**, and no extra data will be collected unless explicitly enabled.
|
|
51
|
+
|
|
52
|
+
To disable additional analytics, set the `TD_ANALYTICS` environment variable to `false`:
|
|
53
|
+
```bash
|
|
54
|
+
TD_ANALYTICS=false
|
|
55
|
+
```
|
|
56
|
+
|
|
57
|
+
## Rate Limiting and Restrictions
|
|
58
|
+
While the TestDriver Agent is free to use, TestDriver reserves the right to rate limit or restrict usage by IP address for any reason.
|
|
59
|
+
|
|
60
|
+
## Notes
|
|
61
|
+
- The TestDriver Agent is essential for providing the AI with the necessary context to operate effectively.
|
|
62
|
+
- For privacy-conscious users, running TestDriver in a virtual machine is recommended to limit exposure of sensitive desktop information.
|
|
File without changes
|
|
@@ -0,0 +1,54 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Security Features of the Dashboard"
|
|
3
|
+
sidebarTitle: "TestDriver Platform"
|
|
4
|
+
description: "Learn about the security features of the TestDriver web dashboard, including SSL, OAuth, RBAC, and more."
|
|
5
|
+
---
|
|
6
|
+
|
|
7
|
+
# TestDriver Web Dashboard Security
|
|
8
|
+
|
|
9
|
+
## Overview
|
|
10
|
+
The TestDriver web dashboard provides a secure interface for managing and reviewing your tests. Tests executed via the GitHub Action are recorded and reported through Dashcam, another application developed by TestDriver. For more details, refer to the [Dashcam documentation](https://dashcam.docs.testdriver.ai).
|
|
11
|
+
|
|
12
|
+
Dashcam and TestDriver share the same API and web application back end, which includes robust privacy and security features.
|
|
13
|
+
|
|
14
|
+
## Security Features
|
|
15
|
+
|
|
16
|
+
### SSL
|
|
17
|
+
- All data transmitted between your browser and the TestDriver web application is encrypted using HTTPS.
|
|
18
|
+
|
|
19
|
+
### OAuth Authentication
|
|
20
|
+
- Users can only authenticate via OAuth, provided by Auth0, ensuring secure and reliable user authentication.
|
|
21
|
+
|
|
22
|
+
### Team Management
|
|
23
|
+
- Administrators can add or remove individual team members.
|
|
24
|
+
- Only administrators have the ability to manage team settings.
|
|
25
|
+
|
|
26
|
+
### Role-Based Access Control (RBAC)
|
|
27
|
+
- The first user to create a team is designated as the administrator.
|
|
28
|
+
- Administrators:
|
|
29
|
+
- Are the only users who can view the API key.
|
|
30
|
+
- Can manage team settings.
|
|
31
|
+
- Cannot be removed from the team.
|
|
32
|
+
- All other users are normal members with limited access.
|
|
33
|
+
|
|
34
|
+
### API Key Rotation
|
|
35
|
+
- Teams can rotate their API key for enhanced security.
|
|
36
|
+
- It is recommended to rotate the API key every 90 days to minimize risk.
|
|
37
|
+
|
|
38
|
+
### Secret Masking
|
|
39
|
+
- Test replay logs and network requests are automatically scanned for sensitive information, such as:
|
|
40
|
+
- Credit card numbers
|
|
41
|
+
- Emails
|
|
42
|
+
- Passwords
|
|
43
|
+
- API keys
|
|
44
|
+
- Detected secrets are masked with asterisks (`****`) to prevent exposure.
|
|
45
|
+
|
|
46
|
+
### Encrypted At Rest
|
|
47
|
+
- Test replays and logs are securely stored on Amazon S3 and encrypted at rest.
|
|
48
|
+
- Test results are only accessible via temporary signed URLs.
|
|
49
|
+
- Signed URLs are generated exclusively for team users and expire after a set duration.
|
|
50
|
+
|
|
51
|
+
## Notes
|
|
52
|
+
- The TestDriver web dashboard is designed with privacy and security as top priorities.
|
|
53
|
+
- For additional security, ensure your team rotates API keys regularly and reviews team member access permissions.
|
|
54
|
+
- If you have specific security concerns or questions, please contact TestDriver support.
|
|
@@ -0,0 +1,79 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Tutorial: Advanced Test"
|
|
3
|
+
description: "Explore advanced testing techniques and features in TestDriver."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Advanced Test Tutorial
|
|
7
|
+
|
|
8
|
+
Welcome to the Advanced Test Tutorial. In this guide, we will explore advanced testing techniques and features available in TestDriver. This tutorial assumes you have a basic understanding of TestDriver and its functionalities.
|
|
9
|
+
|
|
10
|
+
## Prerequisites
|
|
11
|
+
|
|
12
|
+
Before starting, ensure you have completed the basic TestDriver tutorial and have the following:
|
|
13
|
+
|
|
14
|
+
- TestDriver installed and configured.
|
|
15
|
+
- A sample project to test.
|
|
16
|
+
|
|
17
|
+
## Advanced Features Overview
|
|
18
|
+
|
|
19
|
+
TestDriver provides several advanced features to enhance your testing capabilities:
|
|
20
|
+
|
|
21
|
+
1. **Custom Assertions**: Create custom assertions to validate specific conditions.
|
|
22
|
+
2. **Parameterized Tests**: Run tests with different sets of input data.
|
|
23
|
+
3. **Test Hooks**: Use hooks to execute code before or after tests.
|
|
24
|
+
4. **Parallel Execution**: Speed up testing by running tests in parallel.
|
|
25
|
+
|
|
26
|
+
## Step-by-Step Guide
|
|
27
|
+
|
|
28
|
+
### Step 1: Setting Up Custom Assertions
|
|
29
|
+
|
|
30
|
+
Custom assertions allow you to define specific conditions for your tests. Here's an example:
|
|
31
|
+
|
|
32
|
+
```python
|
|
33
|
+
def assert_custom_condition(value):
|
|
34
|
+
assert value > 0, "Value must be greater than 0"
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
### Step 2: Using Parameterized Tests
|
|
38
|
+
|
|
39
|
+
Parameterized tests enable you to test multiple scenarios with different inputs. Example:
|
|
40
|
+
|
|
41
|
+
```python
|
|
42
|
+
import pytest
|
|
43
|
+
|
|
44
|
+
@pytest.mark.parametrize("input,expected", [(1, True), (0, False)])
|
|
45
|
+
def test_is_positive(input, expected):
|
|
46
|
+
assert (input > 0) == expected
|
|
47
|
+
```
|
|
48
|
+
|
|
49
|
+
### Step 3: Implementing Test Hooks
|
|
50
|
+
|
|
51
|
+
Test hooks let you execute code before or after tests. Example:
|
|
52
|
+
|
|
53
|
+
```python
|
|
54
|
+
def setup_function():
|
|
55
|
+
print("Setting up test environment")
|
|
56
|
+
|
|
57
|
+
def teardown_function():
|
|
58
|
+
print("Cleaning up test environment")
|
|
59
|
+
```
|
|
60
|
+
|
|
61
|
+
### Step 4: Running Tests in Parallel
|
|
62
|
+
|
|
63
|
+
Parallel execution can be achieved using pytest-xdist. Install it with:
|
|
64
|
+
|
|
65
|
+
```bash
|
|
66
|
+
pip install pytest-xdist
|
|
67
|
+
```
|
|
68
|
+
|
|
69
|
+
Run tests in parallel using:
|
|
70
|
+
|
|
71
|
+
```bash
|
|
72
|
+
pytest -n 4
|
|
73
|
+
```
|
|
74
|
+
|
|
75
|
+
## Conclusion
|
|
76
|
+
|
|
77
|
+
By leveraging these advanced features, you can create more robust and efficient tests for your projects. Experiment with these techniques to find the best fit for your testing needs.
|
|
78
|
+
|
|
79
|
+
Happy testing!
|
|
@@ -0,0 +1,41 @@
|
|
|
1
|
+
---
|
|
2
|
+
title: "Tutorial: Basic Test"
|
|
3
|
+
description: "Learn how to create and run a basic test using TestDriver."
|
|
4
|
+
---
|
|
5
|
+
|
|
6
|
+
# Basic Test Tutorial
|
|
7
|
+
|
|
8
|
+
This tutorial will guide you through the process of creating and running a basic test using TestDriver.
|
|
9
|
+
|
|
10
|
+
## Prerequisites
|
|
11
|
+
|
|
12
|
+
Before you begin, ensure you have the following:
|
|
13
|
+
- TestDriver installed on your system.
|
|
14
|
+
- Basic understanding of how TestDriver works.
|
|
15
|
+
|
|
16
|
+
## Step 1: Create a Test
|
|
17
|
+
|
|
18
|
+
To create a test, follow these steps:
|
|
19
|
+
1. Open your code editor.
|
|
20
|
+
2. Write the test script using TestDriver's syntax.
|
|
21
|
+
3. Save the test script with a `.td` extension.
|
|
22
|
+
|
|
23
|
+
Example:
|
|
24
|
+
```plaintext
|
|
25
|
+
test("Example Test", () => {
|
|
26
|
+
expect(1 + 1).toBe(2);
|
|
27
|
+
});
|
|
28
|
+
```
|
|
29
|
+
|
|
30
|
+
## Step 2: Run the Test
|
|
31
|
+
|
|
32
|
+
To run the test, use the following command:
|
|
33
|
+
```plaintext
|
|
34
|
+
testdriver run example-test.td
|
|
35
|
+
```
|
|
36
|
+
|
|
37
|
+
This will execute the test and display the results in the console.
|
|
38
|
+
|
|
39
|
+
## Conclusion
|
|
40
|
+
|
|
41
|
+
You have successfully created and run a basic test using TestDriver. Explore more advanced features to enhance your testing capabilities.
|
|
Binary file
|
package/electron/overlay.html
CHANGED
|
@@ -16,6 +16,11 @@
|
|
|
16
16
|
font-weight: 400;
|
|
17
17
|
font-style: normal;
|
|
18
18
|
font-size: 14px;
|
|
19
|
+
scrollbar-width: none; /* Hide scrollbars for Firefox */
|
|
20
|
+
}
|
|
21
|
+
|
|
22
|
+
*::-webkit-scrollbar {
|
|
23
|
+
display: none; /* Hide scrollbars for WebKit browsers */
|
|
19
24
|
}
|
|
20
25
|
|
|
21
26
|
@keyframes animate-glow {
|
|
@@ -189,10 +194,10 @@
|
|
|
189
194
|
#terminal-wrapper {
|
|
190
195
|
pointer-events: none;
|
|
191
196
|
position: absolute;
|
|
192
|
-
|
|
197
|
+
right: calc(100vw - 600px);
|
|
193
198
|
top: 0px;
|
|
194
199
|
height: 100vh;
|
|
195
|
-
width:
|
|
200
|
+
width: 600px;
|
|
196
201
|
background: black;
|
|
197
202
|
opacity: 0;
|
|
198
203
|
z-index: -1;
|
|
@@ -239,7 +244,6 @@
|
|
|
239
244
|
<div id="mouse"><div id="dot"></div></div>
|
|
240
245
|
</div>
|
|
241
246
|
<div id="terminal-wrapper">
|
|
242
|
-
<img src="td.png" alt="td" style="position: absolute; top: 20; right: 20; height: 40px; z-index: 9999; background-color: black;">
|
|
243
247
|
<div id="terminal"></div>
|
|
244
248
|
</div>
|
|
245
249
|
</div>
|