Help us improve
Share bugs, ideas, or general feedback.
From ce
Fixes flaky tests by replacing arbitrary timeouts with condition polling for async operations, intermittent failures, and setTimeout/sleep delays.
npx claudepluginhub rileyhilliard/claude-essentials --plugin ceHow this skill is triggered — by the user, by Claude, or both
Slash command
/ce:condition-based-waitingThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
**Use with:** `writing-tests` skill for overall test guidance. This skill focuses on timing-based flakiness.
Replaces arbitrary timeouts like setTimeout or sleep with condition polling to fix flaky tests from race conditions, timing dependencies, and inconsistent behavior.
Guides writing and reviewing tests with philosophy, Arrange-Act-Assert structure, condition-based waiting via polling, strategic mocking, and isolation principles.
Guides writing and reviewing tests with philosophy, table-driven tests (Go example), condition-based waiting (TypeScript), strategic mocking, and isolation.
Share bugs, ideas, or general feedback.
Use with: writing-tests skill for overall test guidance. This skill focuses on timing-based flakiness.
Related: If tests pass alone but fail concurrently, the problem may be shared state, not timing. See fixing-flaky-tests skill for diagnosis.
Flaky tests often guess at timing with arbitrary delays. This creates race conditions where tests pass on fast machines but fail under load or in CI.
Core principle: Wait for the actual condition you care about, not a guess about how long it takes.
Test has arbitrary delay (setTimeout/sleep)?
│
├─ Testing actual timing (debounce, throttle)?
│ └─ Yes → Keep timeout, document WHY
│
└─ No → Replace with condition-based waiting
Use when:
setTimeout, sleep, time.sleep())Don't use when:
fixing-flaky-tests)// Bad: Guessing at timing
await new Promise((r) => setTimeout(r, 50));
const result = getResult();
expect(result).toBeDefined();
// Good: Waiting for condition (returns the result)
const result = await waitFor(() => getResult(), 'result to be available');
expect(result).toBeDefined();
Prefer framework built-ins when available:
findBy queries, waitForexpect(locator).toBeVisible()asyncio.wait_for, tenacityCustom polling fallback when built-ins aren't enough:
async function waitFor<T>(
condition: () => T | undefined | null | false,
description: string,
timeoutMs = 5000
): Promise<T> {
const startTime = Date.now();
while (true) {
const result = condition();
if (result) return result;
if (Date.now() - startTime > timeoutMs) {
throw new Error(`Timeout waiting for ${description} after ${timeoutMs}ms`);
}
await new Promise((r) => setTimeout(r, 50)); // Poll interval
}
}
Common use cases:
waitFor(() => events.find(e => e.type === 'DONE'), 'done event')waitFor(() => machine.state === 'ready', 'ready state')waitFor(() => items.length >= 5, '5+ items')| Stack | Reference |
|---|---|
| Python (pytest, asyncio, tenacity) | references/python.md |
| TypeScript (Jest, Testing Library, Playwright) | references/typescript.md |
| Mistake | Problem | Fix |
|---|---|---|
| Polling too fast | setTimeout(check, 1) wastes CPU | Poll every 50ms |
| No timeout | Loop forever if condition never met | Always include timeout |
| Stale data | Caching state before loop | Call getter inside loop |
| No description | "Timeout" with no context | Include what you waited for |
// Tool ticks every 100ms - need 2 ticks to verify partial output
await waitForEvent(manager, "TOOL_STARTED"); // First: wait for condition
await new Promise((r) => setTimeout(r, 200)); // Then: wait for timed behavior
// 200ms = 2 ticks at 100ms intervals - documented and justified
Requirements: