e2e-testing
Skill8 starsChanged 3 months agoMITView on GitHub
Write and review Playwright E2E tests for Langflow. Trigger when the user asks to write, fix, or review E2E tests, spec files, Playwright tests, or integration tests that exercise the full UI. Also trigger when modifying data-testid attributes, test helpers in tests/utils/, or fixture configuration.
- Reads credentials
92 other projects use a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- Rojios/everything-claude-codetheir own version, first seen Nov 8, 2026
- op3616windows/skillstheir own version, first seen Nov 8, 2026
- Lukk17/agent-standardstheir own version, first seen Nov 7, 2026
- pankaj-mahaur/Agent-Daemontheir own version, first seen Nov 6, 2026
- Cure-Consulting-Group/ProductEngineeringSkillstheir own version, first seen Nov 4, 2026
- TsinHzl/claude-code-configtheir own version, first seen Nov 1, 2026
Used with
Projects with it also use everything-claude-code, investor-materials and 9 more.
Other files people use alongside this one.
Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
InfopibeSkilleverything-claude-code
Also in 10 projects that use this
InfopibeSkillinvestor-materials
Create and update pitch decks, one-pagers, investor memos, accelerator applications, financial models, and fundraising materials. Use when the user needs investor-facing documents, projections, use-of-funds tables, milestone plans, or materials that must stay internally consistent across multiple fundraising assets.
Also in 28 projects that use this
mryeastcodeSkilleverything-claude-code-conventions
Development conventions and patterns for everything-claude-code. JavaScript project with conventional commits.
Also in 8 projects that use this
tpavanipradeepSkillbun-runtime
Bun as runtime, package manager, bundler, and test runner. When to choose Bun vs Node, migration notes, and Vercel support.
Also in 18 projects that use this
niloykumarbarmanSkillagent-sort
Build an evidence-backed ECC install plan for a specific repo by sorting skills, commands, rules, hooks, and extras into DAILY vs LIBRARY buckets using parallel repo-aware review passes. Use when ECC should be trimmed to what a project actually needs instead of loading the full bundle.
Also in 8 projects that use this
niloykumarbarmanSkillproduct-capability
Translate PRD intent, roadmap asks, or product discussions into an implementation-ready capability plan that exposes constraints, invariants, interfaces, and unresolved decisions before multi-service work starts. Use when the user needs an ECC-native PRD-to-SRS lane instead of vague planning prose.
Also in 9 projects that use this
- +1 more from Infopibe
Other versions92 projects use a version of this.
Word for word · 1
- langflow-ai/langflow★ 156k100% same
Edited · 1
- factor241/ketos-bot★ 196% same
Wrote their own version · 90
- affaan-m/ECC★ 246ksame name
- All-Hands-AI/OpenHands★ 93ksame name
- OpenHands/OpenHands★ 93ksame name
- pulsejet/memories★ 3.9ksame name
- xu-xiang/everything-claude-code-zh★ 1.9ksame name
- paradigmxyz/centaur★ 1.4ksame name
- etewiah/property_web_builder★ 644same name
- nodetool-ai/nodetool★ 615same name
- Opentrons/opentrons★ 532same name
- loulanyue/awesome-claude-notes★ 272same name
80 more not listed
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- .cursor/rules/docs_development.mdcCursor rule
- backend-code-reviewSkill
- component-refactoringSkill
- frontend-code-reviewSkill
- frontend-i18nSkill
- frontend-query-mutationSkill
- frontend-testingSkill
- ibm-a11y-level1-auditSkill
- ibm-a11y-pr-remediationSkill
- ibm-a11y-route-scanSkill
- ibm-a11y-testing-guideSkill
The file
We split this skill into the rules it gives an agent
5 rules. 0 are common, 2 are distinctive, and 3 are very specific to this project.
0
Common
Most of the 39 edited versions we read keep these.
2
Distinctive
This author's own choices. Worth a look.
3
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 16
Do NOT apply: when:
- Very specific: line 170
Every test MUST be tagged with @release — the release run greps for it, so an untagged or wrongly-tagged spec silently drops out of release …
- Very specific: line 256
When a component field has a global variable selected (load_from_db: true + value: "OPENAI_API_KEY"), the field renders a badge instead of …
- Very specific: line 340
Don't forget
enableInspectPanel(page): before accessing edit-fields-button - Distinctive: line 341
Don't assume input fields exist: when global variables are selected (badge renders instead)
“Common” is measured: kept by at least 6 in 10 of the 39 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Langflow E2E Testing (Playwright)
When to Apply
- User asks to write E2E tests for a feature or flow
- User asks to fix a failing E2E test
- User asks to review E2E test coverage
- User modifies
data-testidattributes in components (may break existing tests) - User changes test utilities in
src/frontend/tests/utils/
Do NOT apply when:
- User asks about unit tests (use
frontend-testingskill for Jest) - User asks about backend tests (use
backend-code-reviewskill for pytest)
Tech Stack
| Tool | Version | Purpose |
| Playwright | 1.59.1 | E2E test runner + browser automation |
| Chromium | (bundled) | Default browser (Firefox/Safari disabled) |
| Custom fixtures | tests/fixtures.ts | Auto-detects API errors and flow execution failures |
Key Commands
# Run all E2E tests
npx playwright test
# Run tests filtered by tag
npx playwright test --grep "@release"
npx playwright test --grep "@workspace"
npx playwright test --grep "@starter-projects"
# Run a specific test file
npx playwright test tests/core/features/run-flow.spec.ts
# Debug mode (headed browser + step through)
npx playwright test --debug
# Show HTML report after run
npx playwright show-report
# Update snapshots (if used)
npx playwright test --update-snapshotsConfiguration
File: src/frontend/playwright.config.ts
| Setting | Value | Why |
fullyParallel | true | Tests run in parallel for speed |
timeout | 5 minutes | Flow builds can be slow; prevents false timeouts |
retries | 3 (local), 2 (CI) | Flaky network/rendering issues; retries catch them |
workers | 2 | Balances speed and resource usage |
actionTimeout | 20s | Individual action timeout (click, fill, etc.) |
trace | on-first-retry | Captures trace on failures for debugging |
baseURL | http://localhost:3000 | Vite dev server |
WebServer: Playwright auto-starts backend (uvicorn on 7860) + frontend (npm start on 3000).
Directory Structure
src/frontend/tests/
├── fixtures.ts # Custom test fixture with error detection
├── globalTeardown.ts # Cleanup (removes temp DB after tests)
├── core/
│ ├── features/ # Main feature tests (run-flow, playground, etc.)
│ ├── integrations/ # Starter project / template tests
│ ├── regression/ # Bug regression tests
│ └── unit/ # Component-level Playwright tests
├── extended/
│ ├── features/ # Extended features (MCP, auto-save, etc.)
│ ├── integrations/ # Extended integrations
│ └── regression/ # Extended regressions
└── utils/ # 37+ shared helper functionsFile Naming
- kebab-case with
.spec.tssuffix:run-flow.spec.ts,playground.spec.ts,flow-lock.spec.ts - Template tests may use spaces:
Document QA.spec.ts,Social Media Agent.spec.ts - Sharded tests for parallelization:
chatInputOutputUser-shard-0.spec.ts
Note: E2E tests use
.spec.ts(Playwright convention). Unit tests use.test.tsx(Jest convention). Do not mix them.
Test Anatomy
Basic Test
import { expect, test } from "../../fixtures";
import { awaitBootstrapTest } from "../../utils/await-bootstrap-test";
test(
"user should be able to run a flow successfully",
{ tag: ["@release", "@workspace"] },
async ({ page }) => {
await awaitBootstrapTest(page);
// Arrange: Create a flow
await page.getByTestId("blank-flow").click();
// Act: Add components and run
await page.getByTestId("sidebar-search-input").fill("Chat Output");
// ... setup ...
// Assert: Verify result
await expect(page.getByTestId("build-status-success")).toBeVisible({ timeout: 30000 });
},
);With test.describe
test.describe("Flow Lock Feature", () => {
test(
"should lock and unlock a flow",
{ tag: ["@release", "@api"] },
async ({ page }) => {
// ...
},
);
test(
"should prevent editing when locked",
{ tag: ["@release"] },
async ({ page }) => {
// ...
},
);
});With Serial Mode (tests that depend on order)
test.describe.configure({ mode: "serial" });
test("step 1: create flow", async ({ page }) => { /* ... */ });
test("step 2: edit flow", async ({ page }) => { /* ... */ });
test("step 3: delete flow", async ({ page }) => { /* ... */ });With Event Delivery Modes (streaming/polling/direct)
import { withEventDeliveryModes } from "../../utils/withEventDeliveryModes";
withEventDeliveryModes(
"Document Q&A should work",
{ tag: ["@release", "@starter-projects"] },
async ({ page }) => {
// This test runs 3 times: streaming, polling, direct
// Each mode is configured automatically via route interception
},
);Tags System
Every test MUST be tagged with @release — the release run greps for it, so an
untagged or wrongly-tagged spec silently drops out of release coverage. Add the
domain tag(s) below on top of @release (a test can have more than one). These
six are the only allowed tags; do not invent new ones.
| Tag | Purpose | When to Use |
@release | Part of the release run (required on every spec) | All tests |
@workspace | Workspace/flow management | Creating, editing, deleting flows |
@api | API-dependent features | Tests that call backend endpoints |
@database | Database operations | Tests involving persistence |
@components | Component-level tests | Individual component behavior |
@starter-projects | Template/starter project tests | Pre-built flow templates |
// Right: tag your test
test("my feature test", { tag: ["@release", "@workspace"] }, async ({ page }) => { ... });
// Wrong: no tags — test can't be filtered
test("my feature test", async ({ page }) => { ... });Custom Fixtures: Error Detection
Always import test and expect from ../../fixtures, NOT from @playwright/test.
// Right
import { expect, test } from "../../fixtures";
// Wrong — bypasses error detection
import { expect, test } from "@playwright/test";Why: The custom fixture automatically monitors all /api/ responses and fails the test if:
- HTTP 400, 404, 422, or 500 errors occur
- Flow execution returns
error: truein event streams - Python exceptions appear in streamed responses
To opt-in to expected errors (e.g., testing error handling):
test("should show error on invalid input", { tag: ["@release"] }, async ({ page }) => {
page.allowFlowErrors(); // Allow flow errors for this test
// ... test that expects errors ...
});Selector Strategy
Priority (in order of preference)
getByTestId— Most stable, used 95% of the time in LangflowgetByRole— For buttons, headings, and form elementsgetByText— For visible text contentwaitForSelector— For CSS selectors and dynamic elementslocator— For complex selectors (CSS, XPath)
Common data-testid Patterns
Canvas & Navigation:
blank-flow— New blank flow buttonsidebar-search-input— Component searchcanvas_controls_dropdown— Canvas controls menufit_view,zoom_out,zoom_in— Canvas controlsreact-flow-id— ReactFlow canvas container
Component Fields:
popover-anchor-input-{fieldname}— Input field for a component parameterinput-chat-playground— Playground chat inputdiv-chat-message— Chat message in playground
Actions:
add-component-button-{component}— Add component to canvasbutton-send— Send chat messagebutton_run_{component}— Run specific componentpublish-button,save-flow-button— Flow actionsedit-fields-button— Toggle inspection panel field editor
Modals & Panels:
modal-title— Modal headingicon-Globe— Global variablesicon-Lock— Flow lock togglesession-selector— Playground session switcher
Important: Global Variables and Badges
When a component field has a global variable selected (load_from_db: true + value: "OPENAI_API_KEY"), the field renders a badge instead of an <input> element. This means getByTestId("popover-anchor-input-api_key") will NOT find the element — it doesn't exist in the DOM.
Templates with global variables pre-selected: Market Research, Price Deal Finder, Research Agent. Templates without (input IS rendered): Instagram Copywriter.
Core Helper Functions
Located in src/frontend/tests/utils/:
| Function | What it Does | When to Use |
awaitBootstrapTest(page) | Waits for app to fully load | Start of every test |
initialGPTsetup(page) | Full setup: adjustView → updateComponents → selectModel → addKey → adjustView → unselectNodes | Tests that need OpenAI configured |
adjustScreenView(page, opts?) | Fit view + zoom out | After adding components to canvas |
zoomOut(page, times) | Zoom out N times | When components are too small |
selectGptModel(page) | Selects gpt-4o-mini for all Language Model nodes | GPT-dependent tests |
addOpenAiInputKey(page) | Fills OPENAI_API_KEY for all openai_api_key fields | Tests requiring API key |
enableInspectPanel(page) | Toggles inspection panel ON | MUST call before edit-fields-button |
disableInspectPanel(page) | Toggles inspection panel OFF | Cleanup after inspection |
updateOldComponents(page) | Clicks "Update all" if outdated components exist | After loading saved flows |
unselectNodes(page) | Clicks empty canvas area to deselect all nodes | After node operations |
renameFlow(page, { flowName }) | Renames the current flow | Flow management tests |
uploadFile(page, filename) | Uploads a file from test assets | File upload tests |
withEventDeliveryModes(...) | Runs test 3x: streaming, polling, direct | Starter project tests |
initialGPTsetup Options
await initialGPTsetup(page); // All steps
await initialGPTsetup(page, {
skipAdjustScreenView: true,
skipUpdateOldComponents: true,
skipSelectGptModel: true,
});Inspection Panel Pattern (CRITICAL)
// MUST enable inspection panel FIRST
await enableInspectPanel(page);
// Click a node to select it
await page.getByTestId("title-OpenAI").click();
// Open field editor
await page.getByTestId("edit-fields-button").click();
// Toggle field visibility
await page.getByTestId("showmodel_name").click();
// Close field editor
await page.getByTestId("edit-fields-button").click();If you skip enableInspectPanel(page), the edit-fields-button will NOT be visible.
Skip Patterns
// Skip test if env var missing
test.skip(!process?.env?.OPENAI_API_KEY, "OPENAI_API_KEY required to run this test");
// Skip test unconditionally with reason
test.skip(true, "Feature not yet implemented with new designs");Writing Good E2E Tests
Do:
- Tag every test with
@release(plus any domain tags that apply) - Import from
../../fixtures, not@playwright/test - Start with
awaitBootstrapTest(page)— always - Use
getByTestIdfor stable selectors - Set explicit timeouts on
waitForSelectorandexpect(...).toBeVisible()for async operations - Test the complete user flow: setup → action → verification
- Use
withEventDeliveryModesfor tests that involve flow execution (chat, build)
Don't:
- Don't use
page.waitForTimeout()unless absolutely necessary — preferwaitForSelectororexpect().toBeVisible() - Don't hardcode API keys — read from
process.env.OPENAI_API_KEY - Don't skip tests without a reason — always provide the second argument to
test.skip() - Don't import from
@playwright/test— use the custom fixtures - Don't forget
enableInspectPanel(page)before accessingedit-fields-button - Don't assume input fields exist when global variables are selected (badge renders instead)
Challenge Tests (Apply Here Too)
E2E tests should also cover adversarial scenarios:
- Invalid input: paste 10K characters, special characters (
<script>alert(1)</script>), empty submissions - Network interruption: what happens if the user loses connection mid-build?
- Permission boundaries: can a user access another user's flow via direct URL?
- Concurrent actions: double-click delete, rapid chat messages
- Error recovery: does the UI recover gracefully from a 500 error?
References
- Selector Patterns — Complete data-testid catalog
- Helper Functions — Detailed documentation of all 37+ utility functions
- Test Fixtures — Custom fixture error detection behavior
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.

