Compétences condition-based-waiting

condition-based-waiting

Sûr ⚙️ Commandes externes🌐 Accès réseau📁 Accès au système de fichiers

Elimine testes instáveis com polling condicional

Testes instáveis desperdiçam tempo e reduzem a confiança no seu código. A espera baseada em condições substitui timeouts arbitrários por verificações de estado reais, garantindo que os testes passem de forma confiável em todos os ambientes, incluindo CI.

Prend en charge: Claude Codex Code(CC)
📊 69 Adéquat
1

Télécharger le ZIP du skill

2

Importer dans Claude

Allez dans Paramètres → Capacités → Skills → Importer un skill

3

Activez et commencez à utiliser

Tester

Utilisation de "condition-based-waiting". Help me fix this flaky test that randomly fails in CI: await sleep(300); expect(results.length).toBe(5);

Résultat attendu:

  • Replace the arbitrary 300ms sleep with condition polling:
  • await waitFor(() => results.length === 5, '5 results to be available');
  • This eliminates timing dependency and ensures the test waits for actual state.

Utilisation de "condition-based-waiting". My test passes locally but fails in CI when the server is slow

Résultat attendu:

  • Instead of guessing a timeout value, poll for the condition you actually need:
  • await waitFor(() => server.isReady(), 'server to be ready', 10000);
  • This adapts to actual server speed rather than failing on slow runs.

Utilisation de "condition-based-waiting". I need to wait for 3 API calls to complete before checking the results

Résultat attendu:

  • Use waitForEventCount to accumulate multiple events:
  • await waitForEventCount(threadManager, threadId, 'API_RESPONSE', 3);
  • Then assert on all accumulated results at once.

Audit de sécurité

Sûr
v5 • 1/17/2026

Pure testing utility skill containing only TypeScript polling functions and documentation. All 43 static findings are false positives: JavaScript template literals were misidentified as Ruby shell execution, timing functions were misidentified as weak cryptography, and documentation comments were misidentified as system reconnaissance. No actual risk factors present.

3
Fichiers analysés
465
Lignes analysées
3
résultats
5
Total des audits

Score de qualité

38
Architecture
100
Maintenabilité
87
Contenu
20
Communauté
100
Sécurité
91
Conformité aux spécifications

Ce que vous pouvez construire

Corrigir falhas de teste no CI

Elimine falhas de teste intermitentes que passam localmente, mas falham em ambientes de integração contínua

Testes confiáveis de componentes assíncronos

Escreva testes estáveis para componentes React com mudanças de estado assíncronas sem chamadas sleep frágeis

Estabilidade em testes de integração

Garanta que testes de integração de banco de dados e API passem consistentemente sem falhas de race condition

Essayez ces prompts

Verificação básica de condição
Replace this arbitrary timeout with condition-based waiting: await new Promise(r => setTimeout(r, 100)); expect(element).toBeVisible();
Aguardar evento
Use waitForEvent to wait for a TOOL_RESULT event before asserting on the response data.
Contar eventos
Wait for 3 AGENT_MESSAGE events to accumulate using waitForEventCount before validating the conversation flow.
Predicado personalizado
Create a waitForEventMatch call to wait for an event matching (e) => e.type === 'DATA_READY' && e.payload.id === 'item_123'.

Bonnes pratiques

  • Sempre defina limites de timeout razoáveis (5000ms padrão) com mensagens de erro descritivas
  • Polling a cada 10ms para eficiência—1ms desperdiça CPU, 100ms deixa testes lentos
  • Chame getters de estado dentro do loop de polling, nunca armazene valores antes dele

Éviter

  • Polling muito rápido (a cada 1ms) que desperdiça ciclos de CPU sem benefício
  • Omitir proteção de timeout que causa loops infinitos se a condição nunca for atendida
  • Ler estado fora do loop de polling que captura valores desatualizados

Foire aux questions

Quais frameworks de teste funcionam com esta skill?
Qualquer framework de teste JavaScript ou TypeScript, incluindo Jest, Vitest, Mocha e Playwright.
Quais valores de timeout funcionam melhor?
O padrão de 5000ms funciona para a maioria dos casos. Aumente para ambientes CI lentos ou operações assíncronas complexas.
Isto pode lidar com sincronização entre abas?
Sim, faça polling de uma variável de estado compartilhada que ambas as abas possam ler e atualizar.
Isto modifica meu test runner?
Não, fornece funções utilitárias puras que você chama do seu código de teste existente.
Qual é o atraso inicial do polling?
A primeira verificação é executada imediatamente, depois a cada 10ms.
Como isso é diferente do waitFor do @testing-library?
Isto fornece uma primitiva de nível inferior que você pode adaptar a qualquer condição, não apenas consultas DOM.

Détails du développeur

Structure de fichiers

📄 example.ts

📄 SKILL.md

📄 SKILL.zip