Test a recurring buy and the next run date it sets

The checks that matter

The cadence, the date and the amount all have to be correct, and a customer will only discover a mistake by seeing a charge they did not expect.

• The cadence - every week, selected explicitly rather than left on a default.
• The next run date - shown before the rule is created, so the customer knows when the first charge lands.
• The amount and asset - fifty dollars of ETH, restated in the saved rule.
• The active state - the rule appears in a list of recurring buys with an active status.

The next run date is asserted twice, once as a preview badge and once on the confirmation. A date that changes between the preview and the saved rule is a defect the customer will only notice as an early charge.

The flow as a test file

The frequency is selected before the card is entered, because the cadence determines the next run date the customer is agreeing to when they submit.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/coinbase-clone-app/buy?reset=true
max_steps: 45
tags: [coinbase, fintech, crypto]
---

# Coinbaze 18.2: Recurring buy

Catalog objective: schedule a weekly buy and verify the next run date.
Key assertion: the recurring rule is active with the correct cadence.

## Set the order up
Select "ETH" in "Asset", type "50" into "Amount in USD", and choose "Recurring buy".

## Choose the cadence
Select "Every week" in "Frequency" and verify a badge reads "Next run: 2026-09-22".

## Schedule it
Type "4242 4242 4242 4242" into "Card number" and click the schedule button.

## Verify the rule is active with the right cadence
Verify a green banner titled "Recurring buy scheduled" names a next run of "2026-09-22", and the "Recurring buys (1)" card lists "$50.00 of ETH · Every week" with an active status.

The saved rule is asserted by its full description, amount, asset and cadence together, so a rule that persists the amount but loses the frequency fails.

Step by step coverage

A setup, a preview, a submission and a persisted record.

The count in the recurring buys heading is asserted as part of that final check, which is a cheap way to prove exactly one rule was created rather than none or two.

Adding it to a suite

kane-cli testmd run tests/coinbase/recurring-buy_test.md

Add a variant that cancels the rule, since a recurring charge a customer cannot stop is a materially worse defect than one that never starts.

Scheduled operations are hard to observe and easy to get wrong. Running flows asynchronously covers unattended checks, and the Kane CLI introduction covers getting the first one running.