cli-e2e-test-authoring
Skill321 starsChanged 54 days agoApache-2.0View on GitHub
Guide for adding new end-to-end tests for the Packmind CLI. This skill should be used when creating new test specs in the `apps/cli-e2e-tests/` directory that exercise CLI commands against a real binary and API.
In this repository92 other files it gives its agents.
- AGENTS.mdAGENTS.md
- apps/AGENTS.mdAGENTS.md
- packages/AGENTS.mdAGENTS.md
- apps/CLAUDE.mdCLAUDE.md
- CLAUDE.mdCLAUDE.md
- packages/CLAUDE.mdCLAUDE.md
- .cursor/rules/packmind/standard-backend-tests-redaction.mdcCursor rule
- .cursor/rules/packmind/standard-changelog.mdcCursor rule
- .cursor/rules/packmind/standard-code-comments.mdcCursor rule
- .cursor/rules/packmind/standard-compliance-logging-personal-information.mdcCursor rule
- .cursor/rules/packmind/standard-typescript-good-practices.mdcCursor rule
- agent-skill-frontmatter-auditSkill
- amplitude-listener-events-adoptionSkill
- cli-e2e-test-authoringSkill
- datadog-analysisSkill
- doc-auditSkill
- feature-specSkill
- feature-sprintSkill
- packmind-onboardSkill
- packmind-update-playbookSkill
- playbook-cli-auditSkill
- product-mapSkill
- qa-reviewSkill
- release-proprietarySkill
- upgrade-runtime-stackSkill
- working-with-playground-appSkill
- working-with-pm-design-kitSkill
- agentic-design-sessionSkill
- agentic-doc-ingestSkill
- agentic-feature-framingSkill
- agentic-orchestratorSkill
- agent-skill-frontmatter-auditSkill
- amplitude-listener-events-adoptionSkill
- create-run-e2e-testsSkill
- creating-end-user-documentation-for-packmindSkill
- datadog-analysisSkill
- doc-auditSkill
- feature-flags-auditSkill
- feature-flags-authoringSkill
- feature-specSkill
- feature-sprintSkill
- how-to-write-typeorm-migrations-in-packmindSkill
- improve-claude-mdSkill
- packmind-onboardSkill
- packmind-update-playbookSkill
- playbook-cli-auditSkill
- product-mapSkill
- qa-reviewSkill
- release-proprietarySkill
- upgrade-runtime-stackSkill
- working-with-playground-appSkill
- working-with-pm-design-kitSkill
- agent-skill-frontmatter-auditSkill
- amplitude-listener-events-adoptionSkill
- cli-e2e-test-authoringSkill
- creating-end-user-documentation-for-packmindSkill
- datadog-analysisSkill
- doc-auditSkill
- feature-flags-auditSkill
- feature-flags-authoringSkill
- The first 60 shown.
The file
We split this skill into the rules it gives an agent
10 rules. About 0 are common, 3 are distinctive, and 7 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈3
Distinctive · estimate
This author's own choices. Worth a look.
7
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 10
Add end-to-end tests that exercise the Packmind CLI binary (dist/apps/cli/main.cjs) in realistic conditions.
- Very specific: line 14
All spec files live in apps/cli-e2e-tests/src/ and follow the naming convention <command>.spec.ts.
- Very specific: line 98
Use gateway from the context to seed data before running the CLI:
- Distinctive: line 111
Use file helpers to create or modify files in the test directory:
- Distinctive: line 171
Before writing the test, ask the user: "Is the feature under test gated by a feature flag?"
- Very specific: line 173
If yes, the test must create a user whose email is at @packmind.com so the flag is enabled.
- Distinctive: line 187
When the CLI command under test requires seeding a new type of API resource:
- Very specific: line 189
Add the interface method to helpers/IPackmindGateway.ts.
- Very specific: line 190
Create helpers/gateways/NewResourceGateway.ts implementing the interface
- Very specific: line 191
Add a lazy getter to helpers/gateways/PackmindGateway.ts (reset on initializeWithApiKey)
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
CLI E2E Test Authoring
Overview
Add end-to-end tests that exercise the Packmind CLI binary (dist/apps/cli/main.cjs) in realistic conditions. Tests run the actual CLI as a child process and, when authentication is needed, interact with a running API via HTTP gateways.
Test File Location
All spec files live in apps/cli-e2e-tests/src/ and follow the naming convention <command>.spec.ts.
Choosing a Test Wrapper
Two wrappers are available depending on whether the command requires authentication.
Unauthenticated commands — describeWithTempSpace
Provides an isolated temporary directory. No API required.
import { describeWithTempSpace, runCli } from './helpers';
describeWithTempSpace('my-command without auth', (getContext) => {
let result: Awaited<ReturnType<typeof runCli>>;
beforeEach(async () => {
const { testDir } = await getContext();
result = await runCli('my-command', { cwd: testDir });
});
it('exits with code 1', () => {
expect(result.returnCode).toBe(1);
});
it('shows an error message', () => {
expect(result.stdout).toContain('No credentials found');
});
});Authenticated commands — describeWithUserSignedUp
Extends describeWithTempSpace by creating a real user account, signing in, and generating an API key. Requires a running API at http://localhost:4200.
import { describeWithUserSignedUp, runCli } from './helpers';
describeWithUserSignedUp('my-command with auth', (getContext) => {
let result: Awaited<ReturnType<typeof runCli>>;
beforeEach(async () => {
const { apiKey, testDir } = await getContext();
result = await runCli('my-command', { apiKey, cwd: testDir });
});
it('succeeds', () => {
expect(result.returnCode).toBe(0);
});
it('displays expected output', () => {
expect(result.stdout).toContain('Expected text');
});
});The context object from describeWithUserSignedUp provides:
| Field | Description |
testDir | Isolated temporary directory |
apiKey | Valid API key for the created user |
user | User object (email, etc.) |
organization | Organization the user belongs to |
spaceId | Global space ID for the organization |
gateway | Authenticated gateway to call the API directly |
Setting Up Test Preconditions
Git repository
Commands that interact with git (e.g. diff, install) require a git repo. Call setupGitRepo in beforeEach:
import { setupGitRepo } from './helpers';
beforeEach(async () => {
const { testDir } = await getContext();
await setupGitRepo(testDir);
});Creating API resources
Use gateway from the context to seed data before running the CLI:
beforeEach(async () => {
const { gateway, spaceId, testDir } = await getContext();
await setupGitRepo(testDir);
await gateway.commands.create({ spaceId, /* ... */ });
await gateway.packages.create({ spaceId, /* ... */ });
});File manipulation
Use file helpers to create or modify files in the test directory:
import { readFile, updateFile, fileExists } from './helpers';
const content = readFile('path/to/file.md', testDir);
updateFile('path/to/file.md', 'new content', testDir);
const exists = fileExists('path/to/file.md', testDir);Assertion Patterns
Split assertions into individual it blocks. Store the CLI result in a block-scoped let variable populated by beforeEach:
let result: Awaited<ReturnType<typeof runCli>>;
beforeEach(async () => {
result = await runCli('some-command', { apiKey, cwd: testDir });
});
it('succeeds', () => {
expect(result.returnCode).toBe(0);
});
it('displays the summary', () => {
expect(result.stdout).toContain('1 change submitted');
});Nesting Describes for Multi-Step Scenarios
For commands that require chained operations (e.g. install then modify then diff), nest describe blocks. Each level adds its own beforeEach that builds on the parent context:
describeWithUserSignedUp('diff command', (getContext) => {
beforeEach(async () => {
// setup: git repo + seed data + install
});
describe('when a change is submitted', () => {
beforeEach(async () => {
// modify file + run diff --submit
});
it('succeeds', () => { /* ... */ });
describe('when running diff again', () => {
beforeEach(async () => {
// run diff without --submit
});
it('excludes the already-submitted change', () => { /* ... */ });
});
});
});Feature Flags
Before writing the test, ask the user: "Is the feature under test gated by a feature flag?"
If yes, the test must create a user whose email is at @packmind.com so the flag is enabled. This is controlled by the underFeatureFlag fixture option. Add .use({ underFeatureFlag: true }) immediately after the test wrapper import, before any describe or it blocks:
// When using testWithApi:
testWithApi.use({ underFeatureFlag: true });
// When using testWithUserSignedUp:
testWithUserSignedUp.use({ underFeatureFlag: true });Without this option, the fixture creates a user at @example.com, which does not have feature flags enabled, and the feature under test would not be accessible.
Adding a New Gateway
When the CLI command under test requires seeding a new type of API resource:
- Add the interface method to
helpers/IPackmindGateway.ts. All exposed methods must be typed withGateway<IXxxUseCase>orPublicGateway<IXxxUseCase>(imported from@packmind/types) - Create
helpers/gateways/NewResourceGateway.tsimplementing the interface - Add a lazy getter to
helpers/gateways/PackmindGateway.ts(reset oninitializeWithApiKey) - Re-export from
helpers/index.ts
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

