condition-based-waiting

Replace arbitrary timeouts with waitFor polling for state changes in tests.

68|6|Updated Apr 16, 2020
One-click install
npx skills add https://github.com/zenobi-us/dotfiles --skill condition-based-waiting-zenobi-us
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: condition-based-waiting
Source: https://github.com/zenobi-us/dotfiles/tree/main/devtools/files/opencode/skills/condition-based-waiting
Command: npx skills add https://github.com/zenobi-us/dotfiles --skill condition-based-waiting-zenobi-us

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes scripts (resource) components.

What problem does it solves? Tests with arbitrary setTimeout or sleep calls are prone to flakiness, failing inconsistently due to race conditions or timing dependencies, leading to unreliable CI/CD and wasted debugging time.

Core Features & Use Cases

  • Condition Polling: Replaces arbitrary timeouts with a generic waitFor function that polls for actual state changes or events.
  • Flaky Test Elimination: Makes async tests robust and reliable by waiting for the precise condition, not a guessed duration.
  • Clear Error Reporting: Provides descriptive timeout errors if the condition is not met within a specified duration.
  • Use Case: You have a test that intermittently fails because an async operation isn't complete before assertions run. Use this Skill to replace the unreliable setTimeout with a waitFor function that polls for the actual state change, making your test robust and reliable.

Quick Start

Use the condition-based-waiting skill to refactor a flaky test that uses setTimeout(..., 50) by replacing it with a waitFor call that checks for a specific event.

Frequently Asked Questions about condition-based-waiting

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I fix flaky tests caused by race conditions and timing dependencies?

Replace arbitrary timeouts with condition polling using a waitFor function that checks for actual state changes. This eliminates race conditions by waiting for the precise condition to be met rather than guessing a duration, making async tests deterministic and reliable.

What's the best way to wait for asynchronous operations in tests instead of setTimeout?

Use condition-based waiting to poll for the specific event or state readiness you need. A generic polling loop with timeout replaces arbitrary sleep calls, providing clear timeout errors if the condition isn't met within the specified duration.

Can I eliminate flaky tests in both unit and integration tests?

Yes. Condition-based waiting applies to unit and integration tests facing race conditions. It covers waits for events, state readiness, file presence, and asynchronous operations, replacing unreliable timeouts with deterministic condition polling across your test suite.

Why do tests with setTimeout fail intermittently?

Arbitrary timeouts guess at completion duration but don't verify actual state changes, causing intermittent failures when operations take longer than expected. Condition polling waits for the actual event, ensuring tests pass consistently regardless of timing variations.

How do I get better error messages when async operations time out in tests?

Condition-based waiting provides descriptive timeout errors that indicate which condition wasn't met. This clarity cuts debugging time by pinpointing the exact state that failed to change, rather than generic timeout messages from sleep calls.