Target seeded fixtures by run-id query instead of first-row taps in destructive flows

JorgeMucientes · JorgeMucientes · commit 9b9f7e8c1407 · 2026-07-04T21:07:13.000+02:00
diff --git a/.maestro/flows/orders_cash_payment.yaml b/.maestro/flows/orders_cash_payment.yaml
@@ -3,18 +3,17 @@
 # P2 ref: Orders > Collect payment using cash on delivery
 #
 # Verifies:
-#   - Filter the orders list by "Processing" status
-#   - Open a processing order
+#   - Search locates this run's seeded pending-payment order
 #   - Tap "Collect Payment" in the payment info section
 #   - Pick the "Cash" option on the Select Payment Method screen
 #   - Change Due Calculator opens with the order total pre-filled
 #   - Tap "Mark Order as Complete" to record the cash payment
 #   - Returns to the order detail/list with the order marked completed
 #
-# Note: unlike mark-complete, the cash-payment flow has no undo — the
-# order stays Completed with a "Cash on Delivery" gateway recorded.
-# The staging store has plenty of processing orders, so one-per-run is
-# acceptable for smoke purposes.
+# Note: the cash-payment flow has no undo — the order stays Completed
+# with a "Cash on Delivery" gateway recorded. It therefore only ever
+# consumes a seeded fixture order (located via ${SUITE_RUN_ID} search),
+# never an arbitrary order from the shared store's list.
 appId: com.woocommerce.android.dev
 name: "Orders - Collect cash payment"
 tags:
@@ -29,62 +28,36 @@ tags:
 - runFlow:
     file: ../subflows/navigate_to_orders.yaml
 
-# ── Filter by Pending payment status ──────────────────────────────────
-# "Processing" orders on this store have already been paid (the payment
-# info shows "Payment complete."), so the Collect Payment button is
-# hidden. "Pending payment" orders are awaiting payment and expose the
-# collect-payment action that the cash flow tests. Clear any
-# previously-applied filters first to avoid cross-test contamination.
+# ── Find this run's seeded pending-payment order ──────────────────────
+# Fixtures are located by query, never by list position — on the shared
+# store the first pending order can be a manual tester's real order, and
+# this flow's cash payment has no undo. Searching the suite run id only
+# surfaces automation-owned orders (seeded billing name is the run id);
+# a "Pending payment" row is a seeded COD fixture that still exposes the
+# Collect Payment action. If attempt 1 consumed pending-order-1, the
+# retry finds pending-order-2 through the same query.
 - tapOn:
-    id: "btn_order_filter"
-    label: "Open filters"
-
-- runFlow:
-    when:
-      visible: ".*Clear.*"
-    commands:
-      - tapOn:
-          text: ".*Clear.*"
-          label: "Clear existing filters"
+    id: "menu_search"
+    label: "Open order search"
 
 - extendedWaitUntil:
-    visible: "Order Status"
+    visible:
+      id: "search_src_text"
     timeout: 10000
 
 - tapOn:
-    text: "Order Status"
-    label: "Open status filter"
+    id: "search_src_text"
+- inputText: ${SUITE_RUN_ID}
+- pressKey: Enter
 
 - extendedWaitUntil:
     visible: ".*Pending payment.*"
-    timeout: 10000
+    timeout: 20000
+    label: "Wait for a seeded pending-payment order in results"
 
 - tapOn:
     text: ".*Pending payment.*"
-    label: "Select Pending payment status"
-
-- tapOn:
-    id: "showOrdersButton"
-    label: "Apply filter"
-
-- extendedWaitUntil:
-    visible:
-      id: "ordersList"
-    timeout: 15000
-
-# Pull-to-refresh the list so the status filter reflects the latest
-# server state (stale cache can leave a just-completed order at index 0).
-- swipe:
-    from:
-      id: "ordersList"
-    direction: DOWN
-    duration: 800
-
-# ── Open the first pending-payment order ──────────────────────────────
-- tapOn:
-    id: "orderNum"
-    index: 0
-    label: "Open first pending-payment order"
+    label: "Open this run's pending-payment order"
 
 - extendedWaitUntil:
     visible:
@@ -161,22 +134,14 @@ tags:
 
 - takeScreenshot: orders_after_cash_payment
 
-# ── Clear the filter so future runs start from an unfiltered list ────
-- tapOn:
-    id: "btn_order_filter"
-    label: "Re-open filters to clear"
-
+# ── Exit search if still active so downstream flows start clean ──────
 - runFlow:
     when:
-      visible: ".*Clear.*"
+      visible:
+        id: "search_src_text"
     commands:
-      - tapOn:
-          text: ".*Clear.*"
-          label: "Clear filters"
-
-- tapOn:
-    id: "showOrdersButton"
-    label: "Apply cleared filter"
+      - back
+      - back
 
 - extendedWaitUntil:
     visible:
diff --git a/.maestro/flows/orders_details_and_actions.yaml b/.maestro/flows/orders_details_and_actions.yaml
@@ -30,11 +30,34 @@ tags:
 - runFlow:
     file: ../subflows/navigate_to_orders.yaml
 
-# Open the first order
+# Open one of this run's seeded orders — never an arbitrary first row.
+# This flow persists a note on the order it opens, and on the shared
+# store index-0 can be a manual tester's real order. Searching the
+# suite run id scopes the list to automation-owned fixtures only.
+- tapOn:
+    id: "menu_search"
+    label: "Open order search"
+
+- extendedWaitUntil:
+    visible:
+      id: "search_src_text"
+    timeout: 10000
+
+- tapOn:
+    id: "search_src_text"
+- inputText: ${SUITE_RUN_ID}
+- pressKey: Enter
+
+- extendedWaitUntil:
+    visible:
+      id: "orderNum"
+    timeout: 20000
+    label: "Wait for seeded orders in results"
+
 - tapOn:
     id: "orderNum"
     index: 0
-    label: "Tap first order in list"
+    label: "Open first seeded order"
 
 # Wait for order detail
 - extendedWaitUntil:
diff --git a/.maestro/flows/orders_mark_complete.yaml b/.maestro/flows/orders_mark_complete.yaml
@@ -3,15 +3,15 @@
 # P2 ref: Orders > Mark complete
 #
 # Verifies:
-#   - Filter the orders list by "Processing" status
-#   - Open a processing order
+#   - Search locates this run's seeded processing order
 #   - Navigate to the Fulfill screen via "Mark order complete"
 #   - Complete the fulfillment
 #   - "🎉 Order completed!" snackbar appears
 #   - Undo the status change so the staging store stays clean
 #
-# Filtering to "Processing" guarantees the target order has the Mark
-# Complete button visible — it's hidden on already-completed orders.
+# The seeded processing fixture guarantees the target order has the
+# Mark Complete button visible — it's hidden on already-completed
+# orders — and that a missed Undo only ever affects automation data.
 appId: com.woocommerce.android.dev
 name: "Orders - Mark order complete"
 tags:
@@ -26,65 +26,37 @@ tags:
 - runFlow:
     file: ../subflows/navigate_to_orders.yaml
 
-# ── Filter by Processing status ───────────────────────────────────────
-# Clear any previously-applied filter first. Prior flows in the suite
-# (e.g. orders_refund with a Completed filter) can leave a status
-# selected; re-selecting "Processing" on top of that would stack the
-# statuses and surface orders that don't have the Mark Complete
-# button.
+# ── Find this run's seeded processing order ──────────────────────────
+# Fixtures are located by query, never by list position — on the shared
+# store the first processing order can be a manual tester's real order,
+# and the Undo below is best-effort (the snackbar auto-dismisses).
+# Searching the suite run id only surfaces automation-owned orders
+# (seeded billing name is the run id); the "Processing" row is a seeded
+# paid fixture that exposes the Mark Complete action.
 - tapOn:
-    id: "btn_order_filter"
-    label: "Open filters"
-
-- runFlow:
-    when:
-      visible: ".*Clear.*"
-    commands:
-      - tapOn:
-          text: ".*Clear.*"
-          label: "Clear existing filters"
+    id: "menu_search"
+    label: "Open order search"
 
 - extendedWaitUntil:
-    visible: "Order Status"
+    visible:
+      id: "search_src_text"
     timeout: 10000
 
 - tapOn:
-    text: "Order Status"
-    label: "Open status filter"
+    id: "search_src_text"
+- inputText: ${SUITE_RUN_ID}
+- pressKey: Enter
 
-# Status labels include counts, e.g. "Processing (50)".
 - extendedWaitUntil:
     visible: ".*Processing.*"
-    timeout: 10000
+    timeout: 20000
+    label: "Wait for a seeded processing order in results"
 
-- tapOn:
-    text: ".*Processing.*"
-    label: "Select Processing status"
+- takeScreenshot: orders_search_processing
 
 - tapOn:
-    id: "showOrdersButton"
-    label: "Apply filter"
-
-- extendedWaitUntil:
-    visible:
-      id: "ordersList"
-    timeout: 15000
-
-# Pull-to-refresh so the status filter reflects the latest server
-# state — stale caches can leave a just-completed order at index 0.
-- swipe:
-    from:
-      id: "ordersList"
-    direction: DOWN
-    duration: 800
-
-- takeScreenshot: orders_filtered_processing
-
-# ── Open the first processing order ──────────────────────────────────
-- tapOn:
-    id: "orderNum"
-    index: 0
-    label: "Open first processing order"
+    text: ".*Processing.*"
+    label: "Open this run's processing order"
 
 - extendedWaitUntil:
     visible:
@@ -161,22 +133,14 @@ tags:
 
 - takeScreenshot: order_marked_complete_reverted
 
-# ── Clear the filter so future runs start from an unfiltered list ────
-- tapOn:
-    id: "btn_order_filter"
-    label: "Re-open filters to clear"
-
+# ── Exit search if still active so downstream flows start clean ──────
 - runFlow:
     when:
-      visible: ".*Clear.*"
+      visible:
+        id: "search_src_text"
     commands:
-      - tapOn:
-          text: ".*Clear.*"
-          label: "Clear filters"
-
-- tapOn:
-    id: "showOrdersButton"
-    label: "Apply cleared filter"
+      - back
+      - back
 
 - extendedWaitUntil:
     visible:
diff --git a/.maestro/flows/orders_refund.yaml b/.maestro/flows/orders_refund.yaml
@@ -97,8 +97,12 @@ tags:
 # here instead of a leftover "SmokeTest*" customer from a previous
 # suite run — those prior orders will have already been fully
 # refunded and show 0 refundable items on the Issue Refund screen.
-# Fall back to the first completed order when the suite-tagged
-# customer isn't visible (e.g. this flow is run standalone).
+# Fall back to this run's seeded refundable fixture (its billing name
+# is the run id) when the suite-tagged customer isn't visible (e.g.
+# this flow is run standalone). Never fall back to an arbitrary first
+# row — on the shared store that could issue a refund against a manual
+# tester's real order; if neither automation order is visible, failing
+# here is the correct outcome.
 - runFlow:
     when:
       visible: ".*SmokeTest-${SUITE_RUN_ID}.*"
@@ -113,9 +117,9 @@ tags:
       notVisible: ".*SmokeTest-${SUITE_RUN_ID}.*"
     commands:
       - tapOn:
-          id: "orderNum"
-          index: 0
-          label: "Open first completed order (fallback)"
+          text: ".*${SUITE_RUN_ID}.*"
+          retryTapIfNoChange: true
+          label: "Open this run's seeded refundable order (fallback)"
 
 - extendedWaitUntil:
     visible:
diff --git a/.maestro/flows/products_create.yaml b/.maestro/flows/products_create.yaml
@@ -99,14 +99,16 @@ tags:
 - takeScreenshot: product_create_empty_form
 
 # ─────────────────────────────────────────────────────────────────────
-# 2. Name — fixed string so search at the end is deterministic even
-#    after previous runs have accumulated duplicates.
+# 2. Name — stamped with the suite run id so (a) the end-of-flow search
+#    matches exactly this run's product, never a leftover duplicate,
+#    and (b) the stale-orphan sweep can find and delete it if the run
+#    crashes before any cleanup.
 # ─────────────────────────────────────────────────────────────────────
 - tapOn:
     id: "editText"
     label: "Tap product name field"
 
-- inputText: "Maestro Smoke Product"
+- inputText: "Maestro Smoke Product ${SUITE_RUN_ID}"
 
 - hideKeyboard
 
@@ -333,19 +335,20 @@ tags:
 - tapOn:
     id: "search_src_text"
 
-- inputText: "Maestro Smoke"
+- inputText: ${SUITE_RUN_ID}
 
 - hideKeyboard
 
 # The search is debounced, and the staging backend can take a couple
 # of seconds to return results for a just-published product. Generous
-# timeout to accommodate that round-trip.
+# timeout to accommodate that round-trip. Matching on the run id makes
+# this assert immune to leftovers from previous runs.
 - extendedWaitUntil:
-    visible: "Maestro Smoke Product"
+    visible: ".*Maestro Smoke Product ${SUITE_RUN_ID}.*"
     timeout: 30000
     label: "Wait for the new product in search results"
 
-- assertVisible: "Maestro Smoke Product"
+- assertVisible: ".*Maestro Smoke Product ${SUITE_RUN_ID}.*"
 
 - takeScreenshot: product_create_found_in_list
 
diff --git a/.maestro/flows/products_media_upload.yaml b/.maestro/flows/products_media_upload.yaml
