Test add to cart with a product variant

The checks that matter

The interesting part of a variant flow is not that the buttons click. It is that the price and the selection label stay in step with each other, and that the value carried into the cart is the one on screen when the shopper pressed the button.

Each row is asserted on the live page rather than planned in advance, so a price that updates late or not at all is caught at the point it happens instead of surfacing as a confusing cart total three steps later.

The same flow as a test file

The test names the variant buttons and the exact strings the page has to show after each click. The price is part of the assertion, not an afterthought.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/shop-clone-app/dp/sku_headset?reset=true
max_steps: 40
tags: [amazon, e-commerce, variant]
---

# ShopKart 1.2: Add to cart with variant

Catalog objective: pick a size and colour variant and add to cart.
Key assertion: cart shows the exact variant chosen.

## Switch colour to Arctic White
Click "Arctic White" and verify the price reads "$84.99" and the selection reads "Selected: Arctic White · Wireless".

## Switch connection to Wired
Click "Wired" and verify the price reads "$69.99" and the selection reads "Selected: Arctic White · Wired".

## Add the chosen variant to the cart
Click "Add to Cart" and verify a confirmation appears reading "Added to Cart: 1 × Wireless Gaming Headset 7.1 (Arctic White · Wired) at $69.99".

The third step is the one that matters most. It asserts the confirmation text in full, including quantity, product name, both variant values and the price, so a cart that silently keeps the default variant fails here. Run it with:

kane-cli testmd run tests/amazon/add-to-cart-variant_test.md

Run output

All three steps passed. The per step timings show the variant switches costing roughly the same as each other, which is the shape you want: no single interaction hanging on a slow re-render.

---
test: ../add-to-cart-variant_test.md
status: passed
started: 2026-09-21T11:51:14.315Z
duration_s: 131
session_id: 4e2af577-f9f4-424b-b536-42a170ce0285
---

# ShopKart 1.2: Add to cart with variant - Result

## Switch colour to Arctic White ✓ passed (48.7s)
md5: c82629842aeec906c00ef35e80ff23e6
Click "Arctic White" and verify the price reads "$84.99" and the selection reads "Selected: Arctic White · Wireless".

## Switch connection to Wired ✓ passed (41s)
md5: 9ad19623124282193fa9719b9a6c372d
Click "Wired" and verify the price reads "$69.99" and the selection reads "Selected: Arctic White · Wired".

## Add the chosen variant to the cart ✓ passed (36s)
md5: 6c78f257511b11a41b538b28bd4225ec
Click "Add to Cart" and verify a confirmation appears reading "Added to Cart: 1 × Wireless Gaming Headset 7.1 (Arctic White · Wired) at $69.99".

Taking it further

The output is a variant check that a product manager can read and a pipeline can run. Because the assertions quote the real on screen strings, the file doubles as a specification of what the variant widget is supposed to say.

Pair it with a checkout test so the variant is followed all the way to the order record. Assertions in Kane CLI goes deeper on how live page checks are decided, and the pre-PR UI check workflow shows where this fits in a review cycle.