Add tests for the toast queue ordering

[Baskarayelu]

Summary

Vitest test that asserts toasts dismiss FIFO and overlap is capped at 3.

Background

Test coverage in this area is currently thin: regressions can land without a failing build. Adding the cases below will lock the contract in place, document the expected behaviour through executable examples, and shorten review cycles when this code changes again.

Acceptance criteria

• The change matches the summary above.
• The new test fails on the current main before the fix (if this is a regression test) and passes after.
• Tests run on every CI matrix entry, not just the local default.
• Lint, type-check, and tests all pass locally.
• PR description references this issue with Closes #<this-issue>.

Implementation hints

• Pick the right test layer: unit tests inside the affected module for pure logic, integration tests under tests/ for cross-module behaviour.
• Cover the happy path and at least one explicit sad path; the title of this issue describes the boundary that needs to be locked in.
• Where the project uses proptest/fast-check/fc, prefer a property test over many hand-written cases. Commit any failing seed back to the repo.
• Keep test names assertive (returns_zero_when_balance_is_zero), not interrogative.
• New tests should be deterministic: no Date.now()/Math.random() without an injected fake.

Repo-specific notes

• Run npm run lint, npm run build, and the unit tests locally before pushing.
• If you change a public component prop, update the matching Storybook story and the docs/COMPONENTS.md entry.
• Respect the design tokens (CSS variables / Tailwind config); do not hard-code colours, spacing, or radii.

Out of scope

• Unrelated refactors in adjacent files.
• Stylistic-only changes (formatting, renaming) that are not required by the fix.
• Anything beyond the acceptance criteria above; surface follow-ups as separate issues.

How to claim and submit

1. Comment on this issue saying you'd like to take it on; wait for a maintainer to assign you (avoids duplicated effort).
2. Open a PR that references this issue (Closes #<this-issue>).
3. Make sure CI is green and request review from a CODEOWNERS maintainer.
4. PRs that close this issue and pass review may qualify for a reward — see the MAYBE REWARDED label and the GrantFox OSS campaign page.

---

Category: test  ·  Campaign: GrantFox OSS · Official Campaign · Maybe Rewarded

[GBOYEE]

Approach: Toast queue ordering test suite

Adding tests for the toast queue system in ToastProvider to verify FIFO ordering, max-toast limit, and auto-dismiss behavior.

File: src/components/ToastProvider.test.tsx (new — the existing Toast.test.tsx covers the UI component, not the queue logic)

Current queue logic (ToastProvider.tsx lines 35-65):

• MAX_TOASTS = 3 — oldest dropped when full
• TIMEOUTS per severity (info/success: 5s, warning: 8s, danger: manual)
• addToast appends to array, removeToast filters by id

Test cases:

1. FIFO ordering — add 3 toasts, assert DOM order matches insertion order
2. Max-toast eviction — add 4 toasts, assert only 3 visible, first is dropped
3. Auto-dismiss timing — add info toast, vi.advanceTimersByTime(5000), assert removed
4. Danger persists — add danger toast, advance 10s, assert still visible
5. removeAllToasts — add multiple, call removeAll, assert empty
6. Settings integration — set toastsEnabled=false, add toast, assert not rendered

Setup: Use renderHook with <ToastProvider> wrapper, vi.useFakeTimers() for timing tests.

Ready once assigned.

[OmniZlatoon]

@OmniZlatoon has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I ensure you quality work done and expected output for this issue. With my software engineering skills for over 5 years, I guarantee you efficiency in my work.

Please entrust me with this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @OmniZlatoon to this issue.

[iyanumajekodunmi756]

@iyanumajekodunmi756 has applied to work on this issue as part of the Stellar Wave Program's 6th wave.

I would like to work on this issue

ℹ️ Repo Maintainers: To accept this application, review their application or assign @iyanumajekodunmi756 to this issue.

[drips-wave]

Congratulations, @iyanumajekodunmi756! 🎉 Your application was accepted by the repo's maintainers, and the issue is due on June 30, 2026.

🧑‍💻 @iyanumajekodunmi756: Please resolve the issue such that the repo's maintainers have enough time to review your contribution before the due date. You'll earn Points for completing the issue on-time, which will make you eligible for a share of the Stellar Wave Program's reward pool.

Warning

When opening a PR, please link it to this issue to ensure it gets tracked accurately. Points are awarded when this issue is marked as completed by the maintainer.

🤠 Repo maintainers: Please keep an eye on the contributor's progress and review their work before the due date. You can manage this issue, including adjusting its complexity and points, here.

🌊 Happy Wave 🌊