Testdriver:variables Agent Skill
Use dynamic data and secure secrets in your tests
Install
one command, takes just this skill from the repositorynpx skills add https://github.com/testdriverai/testdriverai --skill testdriver:variablesThe instruction itself
3 sections, as written by the author<!-- Generated from variables.mdx. DO NOT EDIT. -->
Scale your testing with dynamic data and secure secrets management. Choose the right approach based on your testing needs.
Environment Variables
Environment variables are ideal for configuration that changes between environments (dev, staging, production) or for secrets that shouldn't be committed to code. Use this approach when you need to run the same tests against different servers or with different credentials.
import { test } from 'vitest';
import { chrome } from 'testdriverai/presets';
test('multi-environment testing', async (context) => {
const env = process.env.TEST_ENV || 'staging';
const urls = {
dev: 'https://dev.myapp.com',
staging: 'https://staging.myapp.com',
production: 'https://myapp.com'
};
const { testdriver } = await chrome(context, {
url: urls[env]
});
await testdriver.assert('app is running');
});
# Run against different environments
TEST_ENV=dev vitest run
TEST_ENV=staging vitest run
TEST_ENV=production vitest run
Test Fixtures
Test fixtures work best when you have structured, reusable test data that needs to be shared across multiple tests. Use fixtures when testing different user roles, product catalogs, or any scenario where you want to parameterize tests with a known set of data.
export const testUsers = [
{ email: '[email protected]', role: 'admin' },
{ email: '[email protected]', role: 'user' },
{ email: '[email protected]', role: 'guest' }
];
export const products = [
{ name: 'Laptop', price: 999 },
{ name: 'Mouse', price: 29 },
{ name: 'Keyboard', price: 89 }
];
import { test } from 'vitest';
import { chrome } from 'testdriverai/presets';
import { testUsers } from './fixtures/users.js';
test.each(testUsers)('$role can access dashboard', async ({ email, role }, context) => {
const { testdriver } = await chrome(context, { url });
await testdriver.find('email input').type(email);
await testdriver.find('password input').type('password123');
await testdriver.find('login button').click();
if (role === 'admin') {
await testdriver.assert('admin panel is visible');
} else {
await testdriver.assert('user dashboard is visible');
}
});
Dynamic Data Generation
Dynamic data generation is perfect for creating unique test data on each run, avoiding conflicts with existing records, and testing edge cases with realistic data. Use libraries like Faker when you need fresh emails, names, or other data that won't collide with previous test runs.
import { test } from 'vitest';
import { chrome } from 'testdriverai/presets';
import { faker } from '@faker-js/faker';
test('user registration with dynamic data', async (context) => {
const { testdriver } = await chrome(context, { url });
// Generate unique test data for each run
const userData = {
firstName: faker.person.firstName(),
lastName: faker.person.lastName(),
email: faker.internet.email(),
password: faker.internet.password({ length: 12 })
};
await testdriver.find('first name input').type(userData.firstName);
await testdriver.find('last name input').type(userData.lastName);
await testdriver.find('email input').type(userData.email);
await testdriver.find('password input').type(userData.password);
await testdriver.find('register button').click();
await testdriver.assert('registration successful');
console.log('Registered user:', userData.email);
});
npm install --save-dev @faker-js/faker
Other skills for the same job
different authors, same section of the catalogue
Toolkit for interacting with and testing local web applications using Playwright. Supports verifying frontend functionality, debugging UI behavior, capturing browser screenshots, and viewing browser logs.
Use when implementation is complete, all tests pass, and you need to decide how to integrate the work - guides completion of development work by presenting structured options for merge, PR, or cleanup
Use when implementing any feature or bugfix, before writing implementation code
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
Use when about to claim work is complete, fixed, or passing, before committing or creating PRs - requires running verification commands and confirming output before making any success claims; evidence before assertions always
Expert guidance for systematic backtesting of trading strategies. Use when developing, testing, stress-testing, or validating quantitative trading strategies. Covers "beating ideas to death" methodology, parameter robustness testing, slippage modeling, bias prevention, and interpreting backtest results. Applicable when user asks about backtesting, strategy validation, robustness testing, avoiding overfitting, or systematic trading development.
Cloud laboratory platform for automated protein testing and validation. Use when designing proteins and needing experimental validation including binding assays, expression testing, thermostability measurements, enzyme activity assays, or protein sequence optimization. Also use for submitting experiments via API, tracking experiment status, downloading results, optimizing protein sequences for better expression using computational tools (NetSolP, SoluProt, SolubleMPNN, ESM), or managing protein design workflows with wet-lab validation.
This skill should be used for time series machine learning tasks including classification, regression, clustering, forecasting, anomaly detection, segmentation, and similarity search. Use when working with temporal data, sequential patterns, or time-indexed observations requiring specialized algorithms beyond standard ML approaches. Particularly suited for univariate and multivariate time series analysis with scikit-learn compatible APIs.
How to use it
Take testdriverai/testdriver:variables from the repository into ~/.claude/skills for personal
use, or into .claude/skills inside a project.
The agent identifies a skill by the name field in its header. Two skills with the
same name cannot sit side by side — one of them will be ignored.
The instructions reference npm.
Without those the skill loads but fails at the first command.