Test that a loyalty points balance renders correctly

The checks that matter

A read-only page needs a different kind of test. There is nothing to submit, so the assertions have to establish that the number on screen is backed by something rather than merely present.

• The balance and its state - 1240 available, alongside a badge reading "Balance available" rather than an error or empty state.
• The ledger behind it - named transactions with signed amounts, an earn of +48 against an order and a redemption of -200.
• The lifetime totals - separate aggregate values that come from a different query than the balance.

Checking the badge alongside the number is what distinguishes this from a presence check. A page that renders 0 with an error badge and a page that renders 0 with an available badge are different situations, and only one of them is a bug.

The same flow as a test file

The step ceiling is 35 here rather than the 45 used for the checkout flows, since there is nothing to submit. Front matter is the right place to keep that guard tight on a short test.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/flipkart-clone-app/rewards?reset=true
max_steps: 35
tags: [flipkart, rewards]
---

# Flipkort 3.4: SuperCoins balance

Catalog objective: open the rewards section and verify the SuperCoins balance renders.
Key assertion: the balance is a number, not an error state.

## Confirm the balance renders as a number
Verify the SuperCoins page shows an available balance of "1240" and a badge reading "Balance available".

## Confirm the ledger backs the balance
Verify the coin history lists an entry "Order OD1180 - earned" with "+48" and an entry "Redeemed on Nexa case" with "-200".

## Confirm lifetime totals are present
Verify the page shows "Lifetime earned" with the value "140" and "Lifetime redeemed" with the value "200".

Run it with:

kane-cli testmd run tests/flipkart/supercoins-balance_test.md

Run output

Three passes in 117 seconds. The last step is the slowest at 52.6 seconds despite being a pure read, because it asserts two separate labelled values on the page.

---
test: ../supercoins-balance_test.md
status: passed
started: 2026-09-15T09:49:46.747Z
duration_s: 117
session_id: 73c7b9df-c7be-4fa9-bf1f-f3b90f535040
---

# Flipkort 3.4: SuperCoins balance - Result

## Confirm the balance renders as a number ✓ passed (32.1s)
md5: 4090e3d6bfa8213ff457c1024485510a
Verify the SuperCoins page shows an available balance of "1240" and a badge reading "Balance available".

## Confirm the ledger backs the balance ✓ passed (28.1s)
md5: 1ae01c583a108f6973525ee5c06fea38
Verify the coin history lists an entry "Order OD1180 - earned" with "+48" and an entry "Redeemed on Nexa case" with "-200".

## Confirm lifetime totals are present ✓ passed (52.6s)
md5: 3366136371deaa64fff91284c6bff641
Verify the page shows "Lifetime earned" with the value "140" and "Lifetime redeemed" with the value "200".

The test asserts the values the page displays. It does not reconcile them against each other, which is a deliberate limit: reconciliation belongs in a service level check against the loyalty API, not in a browser test.

Taking it further

The result is a two-minute guard on a page that usually gets none, written so anyone can see what it claims. Add one per account state you care about, such as a zero balance or a new account, by copying the file and changing the expected values.

For the reconciliation this test deliberately leaves out, drive the loyalty service directly in the same run. API calls from Kane CLI covers chaining a request alongside the UI steps, and the Kane CLI introduction is the starting point if you are setting this up for the first time.