Test adding funds by UPI with validation first

The flow under test

The flow is three checks and a credit, and the first two are about refusing bad input rather than accepting good input.

• The starting margin - 25,000 rupees, established before anything is added.
• A malformed address is refused - with an error naming the expected format.
• A valid address verifies - confirmed by a badge before any amount is entered.
• The credit lands exactly - 5,000 added, taking the margin to 30,000.

The final assertion names the transition from 25,000 to 30,000 rather than just the new figure. A margin that reads 30,000 tells you less than a margin that demonstrably moved by the amount deposited.

The test file

The malformed address error is quoted in full, including the example format, because a generic validation message and a helpful one are different products to a client in a hurry.

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

# Zerodhaa Kyte 17.4: Funds via UPI

Catalog objective: add funds via the UPI test flow.
Key assertion: the available margin increases correctly.

## Verify the starting margin
Verify "Available margin" reads "₹25,000.00".

## Verify a malformed UPI ID is rejected
Type "priya" into "UPI ID", click "Verify UPI ID", and verify an error reads "Enter a valid UPI ID, for example name@bank."

## Verify a good UPI ID
Replace the UPI ID with "priya@okhdfb", click "Verify UPI ID", and verify a badge reads "UPI ID verified".

## Add the funds
Type "5000" into "Amount", click "Add funds", and verify a green banner titled "Funds added" says "₹5,000.00" was credited and the balance moved from ₹25,000.00 to "₹30,000.00", with "Available margin" now reading "₹30,000.00".

Replacing the address between attempts, rather than appending, also exercises whether the previous error clears when the input changes.

Step by step coverage

A baseline, two validation checks, then the credit.

Two of the four steps are about refusing input. On a funding flow that is the right proportion, because the cost of accepting a bad address is far higher than the cost of a rejected one.

Running it

kane-cli testmd run tests/zerodha/funds-upi_test.md

Pair this with the payment funding flows in the same suite so every route into the account is covered by the same kind of check.

Validation cases are mechanical to produce and tedious to write. Generating validation variants covers that, and exact string assertions covers pinning each message.