Test a transaction history filter on two criteria

The contract this flow keeps

A filter makes a claim about everything it hides as well as everything it shows, and only the count makes that claim checkable.

• Unfiltered - six transactions, establishing the full set.
• One filter - two transactions for August, with a total and both merchants named.
• Two filters - one transaction for September in groceries, with its own total.
• The survivor - a single row that satisfies both criteria independently.

Asserting the count at every stage is what makes each filter verifiable. A filter that returns the right row among several wrong ones satisfies a presence check completely.

The objective in plain English

The totals are asserted alongside the counts, since a filtered total that does not correspond to the filtered rows is a separate defect from a wrong row set.

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

# PhonePey 21.3: History filter

Catalog objective: filter the history by month and category.
Key assertion: the filtered list matches both criteria.

## Verify the unfiltered history
With "All" selected for both filters, verify "Transactions shown" reads 6.

## Filter by month
Select "2026-08" in "Month" and verify "Transactions shown" reads 2 with a "Total" of "₹2,160.00", listing "Uber India" and "Adani Electricity".

## Add a category filter
Select "2026-09" in "Month" and "Groceries" in "Category", then verify "Transactions shown" reads 1 with a "Total" of "₹2,140.00".

## Verify the single row matches both criteria
Verify the only row is "BigBazaar" at "₹2,140.00", which is both in 2026-09 and in Groceries.

The final step names the surviving row and states why it qualifies on both criteria, which keeps the expectation and its justification together in the file.

Assertion by assertion

A baseline and three progressively narrower checks.

Changing the month while adding the category in the third step is deliberate. It proves the filters combine rather than one silently overriding the other.

Putting it in CI

kane-cli testmd run tests/phonepe/history-filter_test.md

Add a combination that should return nothing, since an empty state is a filter outcome and often an unhandled one.

Filters are where a plain English test reads most like the requirement it came from. From a PRD to evidence covers that alignment, and Kane CLI as a QA agent covers where support-facing surfaces fit in a suite.