Skip to content

test(workflows): verify purchase/restore callbacks fire from any workflow step#6855

Merged
facumenzella merged 1 commit into
mainfrom
facu/workflow-callbacks
Jun 12, 2026
Merged

test(workflows): verify purchase/restore callbacks fire from any workflow step#6855
facumenzella merged 1 commit into
mainfrom
facu/workflow-callbacks

Conversation

@facumenzella

@facumenzella facumenzella commented May 27, 2026

Copy link
Copy Markdown
Member

What Changed

  • Tests that the workflow paywall's purchase/restore callbacks (onPurchaseStarted/Completed/Cancelled/Failure + the restore variants) fire on the initial step and on a non-initial step.
  • Ended up test-only, no production diff.

Notes

  • WorkflowPaywallView keeps a single purchaseHandler above the per-step PaywallsV2View subtrees that navigation swaps, so the listeners are step-independent by construction. Seeding the view at a non-initial step (via initial_step_id) covers that without any test hook in production.
  • Dropped the #if DEBUG WorkflowNavigationTestDriver + .onReceive seam I had. It drove a real transition but only asserted on the settled state, which the non-initial-step tests already cover, so it wasn't worth a permanent production hook.
  • Covering callbacks during the in-flight animated transition is really a Maestro job (left a note inline).
AI session context

AI Context

Metadata

  • PR: 6855
  • Branch: facu/workflow-callbacks
  • Author / human owner: facumenzella (Facundo Menzella)
  • Agent(s): Claude Code (Opus 4.8, 1M context)
  • Session source: current conversation
  • Generated: 2026-06-12
  • Context document version: 2

Goal

Decide whether the original PR (DEBUG-only navigation test seam to verify purchase/restore callbacks survive workflow step transitions) was worth keeping, then make the PR mergeable.

Initial Prompt

"Let's check PR #6855. What do you think? Is it worth it? Or should we rethink this?" Followed by "How would that look" and "let's go, this is mergeable" — i.e. evaluate the approach, propose a stripped-down alternative, then implement and push it.

Important Follow-up Prompts

  • "How would that look" — asked for the concrete shape of the stripped-down version.
  • "let's go, this is mergeable" — authorization to apply the trim, verify, and push.
  • "update the pr desc and title" — refresh description in a casual voice and retitle as test-only.

Agent Contribution

  • Reviewed the PR diff, inline review threads (vegaro, Cursor Bugbot), and the final branch state.
  • Verified the load-bearing claim by reading WorkflowPaywallView.swift: purchaseHandler is a single shared let above the swapped per-step subtrees, so callback wiring is step-independent.
  • Identified that the tier-3 "after a real navigation transition" tests asserted only on settled post-transition state, duplicating the non-initial-step coverage while costing a permanent #if DEBUG production seam.
  • Reset the branch onto current origin/main, brought the PR's final test file in, trimmed it, and reverted all production changes.
  • Ran the test target to confirm compilation and green tests; force-pushed the single clean commit.

Human Decisions

  • Chose to rethink rather than keep iterating on the seam (aligned with author's own in-thread "I dislike the solution" / "Maestro IMO" comments).
  • Approved the stripped-down plan ("let's go, this is mergeable").

Key Implementation Decisions

  • Decision: Drop the #if DEBUG WorkflowNavigationTestDriver, .onReceive seam, and testing-only initializer; revert WorkflowPaywallView.swift to match main (zero production diff).
    • Rationale: callback forwarding is step-independent by construction; the seam's assertions added no coverage beyond the seed-at-non-initial-step tests.
    • Rejected: keeping the driver to drive a live transition — its assertions only checked settled state, and live in-flight coverage needs UI automation.
  • Decision: Keep 7 initial-step + 7 non-initial-step callback tests using only the public initializer.
    • Rationale: exercises the real PurchaseHandler from any rendered step without production test hooks.

Files / Symbols Touched

  • Tests/RevenueCatUITests/PaywallsV2/WorkflowPaywallViewTests.swift
    • Why: trimmed callback test suite; removed driver-based tests and helper.
    • Symbols: WorkflowPurchaseObserver (trimmed to public init), makeContextStartingAt(stepId:) (kept); removed WorkflowNavigationTestDriver usage, makeNavigableContext(), and ...FiredAfterNavigating* tests.
    • Review relevance: confirm the kept tests rely only on the public WorkflowPaywallView init and the shared PurchaseHandler.
  • RevenueCatUI/Templates/V2/WorkflowPaywallView.swift
    • Why: reverted to main (no production change in this PR).
    • Symbols: none.
    • Review relevance: confirm diff vs main is empty.

Dependencies / Config / Migrations

  • None.

Validation

  • Commands run:
    • xcodebuild test -workspace RevenueCat-Tuist.xcworkspace -scheme RevenueCatUITests -destination 'platform=iOS Simulator,id=<iPhone 17 Pro, iOS 26>' -only-testing:RevenueCatUITests/WorkflowPaywallViewTests: Executed 46 tests, 0 failures. TEST SUCCEEDED.
    • swiftlint (pre-commit hook on the test file): no violations.
    • git diff origin/main -- RevenueCatUI/Templates/V2/WorkflowPaywallView.swift: empty (production untouched).
  • Manual verification:
    • Not run (no behavior change to verify by hand).
  • CI:
    • Not captured at time of writing.

Validation Gaps

  • Callbacks are not tested during the live, in-flight animated two-page transition window (intentional; needs Maestro). Documented inline in the test file.
  • Full RevenueCatUITests suite not run locally; only WorkflowPaywallViewTests was executed.

Review Focus

  • Is the non-initial-step coverage sufficient given callback forwarding is step-independent, or is live-transition coverage still wanted (then it should be a Maestro test, not a unit seam)?
  • Confirm no remaining references to the removed WorkflowNavigationTestDriver / testing-only init anywhere in the codebase.

Risks / Reviewer Notes

  • Risk: a future change could move purchase-callback wiring into the per-step subtree, which these tests would not catch.
    • Evidence: today the handler is a shared let above the swapped subtree.
    • Mitigation: inline note in the test file documents the assumption and points to UI automation for live-transition coverage.

Non-goals / Out of Scope

  • Verifying callbacks during an in-flight animated transition (UI automation territory).
  • Any production behavior change.

Omitted Context

  • Raw transcript, unrelated exploration, sensitive details, repetitive attempts, and chain-of-thought-style content were omitted.

@facumenzella facumenzella changed the title test(workflows): verify purchase/restore callbacks fire from any workflow step feat(workflows): verify purchase/restore callbacks fire from any workflow step May 27, 2026
@facumenzella facumenzella marked this pull request as ready for review May 27, 2026 17:57
@facumenzella facumenzella requested a review from a team as a code owner May 27, 2026 17:57
Comment thread Tests/RevenueCatUITests/PaywallsV2/WorkflowPaywallViewTests.swift

@vegaro vegaro left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tests look good but I am not sure we are covering the real world where navigating back and forth could actually break the listeners?

Comment thread Tests/RevenueCatUITests/PaywallsV2/WorkflowPaywallViewTests.swift
Comment thread Tests/RevenueCatUITests/PaywallsV2/WorkflowPaywallViewTests.swift
Comment thread RevenueCatUI/Templates/V2/WorkflowPaywallView.swift Outdated

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cursor Bugbot has reviewed your changes and found 1 potential issue.

Fix All in Cursor

❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.

Reviewed by Cursor Bugbot for commit 63c3d9a. Configure here.

Comment thread Tests/RevenueCatUITests/PaywallsV2/WorkflowPaywallViewTests.swift Outdated
@facumenzella facumenzella force-pushed the facu/workflow-callbacks branch from 588245c to 5eef730 Compare June 2, 2026 07:51
…flow step

Cover the purchase/restore callbacks (onPurchaseStarted/Completed/Cancelled/Failure,
onRestoreStarted/Completed/Failure) on the initial step and on a non-initial step
(seeded via initial_step_id).

WorkflowPaywallView holds a single purchaseHandler above the per-step PaywallsV2View
subtrees that navigation swaps, so callback forwarding is step-independent by
construction. The non-initial-step tests cover that without any production test seam,
so this drops the earlier #if DEBUG WorkflowNavigationTestDriver / onReceive hook and
the testing-only initializer. Live in-flight transition coverage belongs in UI
automation, noted inline.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@facumenzella facumenzella force-pushed the facu/workflow-callbacks branch from 5eef730 to 4b3f47f Compare June 12, 2026 08:16
@facumenzella

facumenzella commented Jun 12, 2026

Copy link
Copy Markdown
Member Author

Reworked, and dropped the DEBUG navigation seam entirely.

On the "are we covering the real-world navigation case" question: purchaseHandler is a single shared let held above the per-step PaywallsV2View subtrees that navigation swaps, so callback forwarding is step-independent by construction.

@facumenzella facumenzella requested a review from vegaro June 12, 2026 08:21
@facumenzella facumenzella changed the title feat(workflows): verify purchase/restore callbacks fire from any workflow step test(workflows): verify purchase/restore callbacks fire from any workflow step Jun 12, 2026
@facumenzella

Copy link
Copy Markdown
Member Author

@vegaro simplified this one. it does not cover navigation, but still worth the test

@facumenzella facumenzella merged commit 1fdfe36 into main Jun 12, 2026
19 of 22 checks passed
@facumenzella facumenzella deleted the facu/workflow-callbacks branch June 12, 2026 09:14
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants