Test a filtered report and what it leaves out

The checks that matter

A report filter has to be checked on what it kept and what it dropped, and the total has to follow from the rows rather than from the unfiltered set.

Naming the excluded record and the reason is what turns this from a row check into a filter check. A report that includes an out-of-quarter deal inflates the forecast, and the row looks entirely legitimate sitting there.

The flow as a test file

The other two filters are left on All deliberately, so the quarter filter is the only variable and any change in the row set is attributable to it.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/salesforce-clone-app/reports?reset=true
max_steps: 40
tags: [salesforce, crm, reporting]
---

# Salesfource 28.3: Report filter

Catalog objective: run a pipeline report filtered to this quarter.
Key assertion: the report renders rows matching the filter.

## Set the filter
Select "Q4" in "Close quarter", leave "Opportunity owner" on All and "Stage" on All.

## Run the report
Click "Run Report" and verify a "Report results" card appears.

## Verify the rows match the filter
Verify the summary reads "3 records · filtered to quarter Q4" and the rows are "Northwind - Platform Licence", "Brightline - Renewal" and "Harbour - Pilot", with "Cedar Foods - Expansion" excluded because it closes in Q1.

## Verify the total
Verify "Total amount" reads "$80,300.00".

The record count is asserted together with the filter description, which means a report that runs unfiltered and happens to return three rows still fails.

Step by step coverage

A filter, a run, the rows and the total.

Leaving the other filters on All is a deliberate choice. One variable at a time is what makes a filter test diagnostic rather than merely green.

Adding it to a suite

kane-cli testmd run tests/salesforce/report-filter_test.md

Add a filter combination returning nothing, since an empty report should say so rather than render a zero total that reads as a bad quarter.

Reports drift as data changes underneath them. Running Kane CLI in CI covers scheduled checks, and deriving assertions from requirements covers keeping expected figures anchored.