test-loading-state

Test Cubit isWaiting() loading states using Completers to control async timing.

7|Updated Jan 27, 2026
One-click install
npx skills add https://github.com/marcglasberg/bloc_superpowers --skill test-loading-state
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: test-loading-state
Source: https://github.com/marcglasberg/bloc_superpowers/tree/main/.claude/skills/test-loading-state
Command: npx skills add https://github.com/marcglasberg/bloc_superpowers --skill test-loading-state

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Tests isWaiting() behavior in Cubits by using Completers to control asynchronous timing and verify loading states.

Core Features & Use Cases

  • Demonstrates isWaiting() in various key contexts: type key, enum key, and composite key.
  • Validates per-item loading states and independent operation tracking across multiple concurrent operations.
  • Covers success and error paths to ensure loading indicators reset on completion or failure.

Quick Start

Run the unit tests that verify isWaiting() behavior using a mock API and Completers to control async timing.

Frequently Asked Questions about test-loading-state

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

FAQPage Schema
How do I test Cubit isWaiting() loading states with precise timing?

Verify Cubit isWaiting() loading states by using Completers to control asynchronous operations, allowing deterministic unit testing of loading, completion, and error paths.

How do I verify independent loading states for multiple concurrent operations in Cubit unit tests?

Verify independent loading states by tracking multiple concurrent operations with Completers, validating per-item loading signals and composite keys to ensure operations remain isolated.

Can I test both success and error paths for Cubit loading indicators?

Yes, you can test both success and error paths by using mocked APIs and Completers to reproduce async failures and completions, ensuring loading indicators reset correctly in either scenario.

How do you use Completers to control async timing when testing Cubit isWaiting()?

Completers control async timing by allowing you to manually complete or delay futures, replacing real async delays with deterministic triggers to verify isWaiting() behavior accurately.

Does this approach support testing composite keys and per-item loading in Cubits?

Yes, it validates isWaiting() across type keys, enum keys, and composite keys, specifically testing per-item loading states and independent operation tracking for multiple concurrent tasks.

Why are my Cubit isWaiting() unit tests flaky and non-deterministic?

Tests become flaky when relying on real async timing; using Completers and mocked APIs replaces unpredictable delays with deterministic controls to reliably verify loading states.