[QA] Reactions Functionality (JO Task)

[xandreiAThome]

Summary

Perform end-to-end QA testing on the Reactions feature for both articles and comments, covering the full lifecycle: creating, reading, updating, and deleting reactions on both entity types. The goal is to verify that the optimistic update flow, popover interactions (hover, click, long-press), auth gating, and cache invalidation all behave correctly across desktop and mobile viewports.

Scope

API Routes

• GET /api/article-reactions?articleId= — article reactions list
• POST /api/article-reactions — create article reaction
• PATCH /api/article-reactions — update article reaction
• DELETE /api/article-reactions — delete article reaction
• GET /api/comment-reactions?commentId= — comment reactions list
• POST /api/comment-reactions — create comment reaction
• PATCH /api/comment-reactions — update comment reaction
• DELETE /api/comment-reactions — delete comment reaction

UI Components

• ReactionPopover — core shared popover (hover, click, long-press)
• ArticleReactionPopover — article wrapper (article header + landing cards)
• CommentReactionPopover — comment wrapper (inside CommentItem)
• Integration points: ArticleHeader, ArticleItem (landing), CommentItem

Critical Flows

1. Click reaction button (default "like") on an article — create
2. Open reaction picker via hover/long-press and select a non-default type — create
3. Click a different reaction type to switch — update
4. Click the same reaction type to toggle off — delete
5. Verify reaction count increments/decrements correctly
6. Verify top-3 reaction icons update in the button display
7. Repeat all flows 1–6 for comments
8. Two users reacting to the same article/comment (concurrent state)
9. Unauthenticated user clicks reaction — should open login modal
10. Optimistic update: verify UI updates immediately before API responds
11. Optimistic rollback: simulate network failure and verify count reverts
12. Hover open/close timing (800ms open, 300ms close debounce)
13. Long-press on mobile (500ms touch hold to open picker)
14. Quick tap on mobile — should default to "like" without opening picker

Deliverables

• QA Test Report — docs/qa/reactions-qa-report.md documenting all test cases and results using the format in docs/qa/qa-artifact-format.md
• Bug tickets — created as GitHub issues using the QA Bug Report template, or as files in docs/qa/bugs/ for any failures found

Implementation Notes

• Approach: Manual QA across at least two browsers (Chrome + Firefox) and mobile responsive mode. Supplement by reading the existing unit tests in src/__tests__/unit/reactions-routes.test.ts.
• Optimistic update verification: Use browser DevTools to throttle network (Slow 3G) so the optimistic update is visible before the API responds. Verify that the count changes instantly, then settles after the response.
• Rollback testing: Use DevTools to block specific API requests (e.g., PATCH /api/article-reactions) and verify the count reverts to the pre-mutation state with a toast error.
• Auth testing: Test both as a logged-in user and as a guest. Guest click should trigger the login modal, not an API call.
• Edge cases: Rapid sequential clicks (spam the like button), react while another user's reaction is still being created, tab away and come back during mutation.

Acceptance Criteria

• All critical flows (1–14 in Scope) have a corresponding test case in the report
• Each test case includes actual result and pass/fail status
• All failing test cases have an accompanying bug report
• Article and comment reactions are tested separately (not assumed to share behavior)
• Optimistic update behavior is explicitly tested (not just final state)
• npm run build is not affected

Tasks

Setup

• Ensure test DB has a published article and at least one comment with existing reactions
• Have two test Google accounts ready for concurrent reaction testing
• Configure browser DevTools network throttling profiles for optimistic update tests

Test Execution — Article Reactions

• TC-REACTIONS-001 — Click reaction button (default "like") on article
• TC-REACTIONS-002 — Open picker via hover and select alternate type
• TC-REACTIONS-003 — Switch reaction type (update)
• TC-REACTIONS-004 — Toggle off reaction (delete)
• TC-REACTIONS-005 — Verify count and top-3 icons update correctly
• TC-REACTIONS-006 — Two users react to same article concurrently
• TC-REACTIONS-007 — Unauthenticated user clicks reaction

Test Execution — Comment Reactions

• TC-REACTIONS-008 to 014 — Repeat flows 001–007 for comments

Test Execution — Interaction Modes

• TC-REACTIONS-015 — Hover open/close timings
• TC-REACTIONS-016 — Long-press on mobile/touch device
• TC-REACTIONS-017 — Quick tap defaults to "like"
• TC-REACTIONS-018 — Article page and landing card both render reaction popover

Test Execution — Error Handling

• TC-REACTIONS-019 — Optimistic update visible under Slow 3G
• TC-REACTIONS-020 — Network failure: count rolls back + toast shown
• TC-REACTIONS-021 — Rapid sequential clicks on reaction button

Reporting

• Compile all test cases into docs/qa/reactions-qa-report.md
• Create bug report GitHub issues (or docs/qa/bugs/ files) for each failing case
• Final review: ensure all critical flows are covered