Test a premium calculator that recalculates live

The contract this flow keeps

Each input is changed on its own, which is what makes the effect of each attributable.

• The baseline - age 30, ten million cover, 6,100.00 a year and 508.00 a month.
• Age alone - raising it to 45 takes the premium to 11,500.00.
• Cover alone - halving the cover takes it to 5,750.00.
• Tobacco alone - the loading takes it to 8,913.00 with a badge explaining why.

Changing one input at a time is the discipline that makes this useful. Changing two and asserting once tells you the calculator responded, not which input it responded to.

The objective in plain English

The second step states explicitly that no calculate button is pressed, which is the behaviour under test rather than an incidental detail.

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

# Policybaazar 27.4: Premium calculator

Catalog objective: adjust the age and cover in the calculator and verify the premium updates.
Key assertion: the premium recalculates on each change.

## Verify the starting premium
Verify "Age used" reads 30, "Cover" reads "₹10,000,000.00", "Insurer" reads "Meridian Life", "Annual premium" reads "₹6,100.00" and "Monthly equivalent" reads "₹508.00".

## Change the age
Set "Age (exact)" to "45" and verify "Annual premium" immediately recalculates to "₹11,500.00" with no Calculate button pressed.

## Change the cover
Select "₹5,000,000.00" in "Life cover" and verify "Annual premium" recalculates to "₹5,750.00".

## Apply the tobacco loading
Tick "Tobacco user" and verify "Annual premium" recalculates to "₹8,913.00" with a badge reading "Tobacco loading applied".

The tobacco step asserts the badge as well as the figure, so a loading applied without explanation is distinguishable from one applied correctly.

Assertion by assertion

A baseline and three isolated changes.

Asserting the monthly equivalent alongside the annual premium in the baseline covers a conversion that is easy to get wrong and easy to overlook.

Putting it in CI

kane-cli testmd run tests/policybazaar/premium-calculator_test.md

Add a change that should not move the premium, since a calculator that recalculates on every input including irrelevant ones is its own kind of bug.

Reactive forms are where a plain English step is most convenient, because there is no submit to wait on. How assertions resolve on a live page explains why that works, and browser agents is useful background.