Test that a portfolio total equals its positions

The checks that matter

The test is arithmetic performed on screen, which is the only kind of check that can catch a total computed from stale inputs.

The application exposes its own sum check, and the test asserts that it equals the positions value shown above it. Two figures produced by different code paths agreeing is stronger evidence than either one being correct on its own.

The flow as a test file

Each position is asserted with its share count alongside its market value, so a row showing the right value for the wrong quantity fails.

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

# Robinhud 16.3: Portfolio value

Catalog objective: open the portfolio and verify the total equals the sum of its positions.
Key assertion: the total matches the computed position sum.

## Verify the headline total
Verify "Total value" reads "$1,309.60".

## Verify the parts it is made of
Verify "Positions value" reads "$1,059.60" and "Cash" reads "$250.00".

## Verify each position's market value
Verify the AAPL row shows 3 shares with a market value of "$680.40" and the AMZN row shows 2 shares with a market value of "$379.20".

## Verify the sum check agrees
Verify "Sum of position values" reads "$1,059.60", which is the same as "Positions value".

The step ceiling is 40 rather than 45 because nothing is submitted. Keeping the guard tight on a read-only flow means a runaway run stops sooner.

Step by step coverage

The four steps move from the headline down to the components and back up to the check.

Working top down and then confirming bottom up means a failure localises immediately. A wrong total with correct rows is a different bug from correct rows summed wrongly.

Adding it to a suite

kane-cli testmd run tests/robinhood/portfolio-value_test.md

Add a variant for an empty portfolio and one for a single position, since zero and one are where display logic tends to break.

Financial totals are worth checking on every release rather than on request. Kane CLI in a pipeline covers scheduling, and deriving assertions from requirements covers keeping expected figures tied to a source.