Test a money request and repeated reminders

The checks that matter

The second reminder is the whole reason this test exists. One reminder proves the button works; two prove the counter is a counter.

• The request is created - with recipient, amount and note.
• It is pending - listed with a pending badge and a count of one in the heading.
• The first reminder registers - a badge reading one reminder sent.
• The second increments it - two reminders sent, and the request is still pending.

Asserting that the request remains pending after the second reminder is the check most likely to catch a real bug. A reminder that advances the state, or resets the counter, is a plausible implementation error that a single reminder would never reveal.

The flow as a test file

The pending count in the card heading is asserted alongside the row, which proves exactly one request was created rather than a duplicate pair.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/venmo-clone-app/requests?reset=true
max_steps: 40
tags: [venmo, fintech, p2p]
---

# Venmoo 22.2: Request and remind

Catalog objective: request money and send a reminder.
Key assertion: the request is pending with a reminder-sent state.

## Create the request
Select "Mira Shah" in "From", type "65" into "Amount", type "Concert tickets" into "What's it for?", and click "Request".

## Verify the request is pending
Verify the "Pending requests (1)" card shows a row reading "From Mira Shah" for "$65.00" with the note "Concert tickets" and a pending status badge.

## Send a reminder
Click "Send reminder" on that request and verify a badge appears reading "1 reminder sent".

## Send a second reminder
Click "Send reminder" again and verify the badge now reads "2 reminders sent" while the request is still pending.

The final assertion pairs the incremented count with the unchanged status, so a reminder that increments correctly while advancing the request still fails.

Step by step coverage

A creation, a state check and two reminders.

Two identical actions with different expected results is a pattern worth reusing anywhere a counter is involved.

Adding it to a suite

kane-cli testmd run tests/venmo/request-and-remind_test.md

Add a cancellation variant, since a request that cannot be withdrawn keeps pressuring someone who has already settled another way.

Counters and accumulating state are easy to get subtly wrong. How assertions resolve against a live page covers checking a value after a repeated action, and the test.md format covers keeping related flows together.