Test cash on delivery checkout

Failure modes in this flow

COD bugs are mostly status bugs. The order goes through, the warehouse picks it, and the record says something the finance system reads incorrectly.

• The handling fee is missing or wrong - 25.00 is added for COD, and a total without it undercharges every order.
• The total ignores the fee - the fee renders as a line but the payable amount does not move.
• The status reads as paid - a COD order marked paid on creation misreports revenue until the courier reconciles.

The fourth step asserts the status string in full, "Confirmed, pay on delivery", rather than checking that a confirmation page appeared. That is the assertion that catches the third failure mode.

Writing the objective

The first step compresses search, product selection, size choice and add to cart into one instruction, because none of that is what this test is about. The COD-specific assertions get a step each.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/flipkart-clone-app?reset=true
max_steps: 45
tags: [flipkart, e-commerce, cod]
---

# Flipkort 3.3: COD checkout

Catalog objective: complete a checkout choosing cash on delivery.
Key assertion: confirmation shows COD as the payment mode.

## Add an item to the cart
Type "running shoes" into the search box, click "Search", click "Trailburst Running Shoes", click size "8", then click "Add to cart" and verify the cart shows "Trailburst Running Shoes".

## Go to checkout
Click "Place order" and verify the checkout page shows a "Payment mode" section listing "Cash on Delivery".

## Choose cash on delivery
Click "Cash on Delivery" and verify the price details show a "COD handling fee" of "₹25.00" and a total payable of "₹2,564.00".

## Confirm the order
Click "Confirm COD order" and verify the page shows "Order confirmed" with a payment mode of "Cash on Delivery" and an order status of "Confirmed - pay on delivery".

That is a deliberate trade. Setup steps are cheap to compress, and the steps carrying the actual subject of the test stay separate so a failure points at the right thing. Run it with:

kane-cli testmd run tests/flipkart/cod-checkout_test.md

Running it locally

Four passes, evenly spread across 179 seconds with no single step dominating. Selecting cash on delivery was the slowest at 47.1 seconds, since it re-renders the price details before the assertion can run.

---
test: ../cod-checkout_test.md
status: passed
started: 2026-09-15T09:46:31.154Z
duration_s: 179
session_id: 89f38865-4867-4cbb-86d6-71f84554dd1c
---

# Flipkort 3.3: COD checkout - Result

## Add an item to the cart ✓ passed (51.4s)
md5: ed5285972cd8255b8687e19c26b2bd3f
Type "running shoes" into the search box, click "Search", click "Trailburst Running Shoes", click size "8", then click "Add to cart" and verify the cart shows "Trailburst Running Shoes".

## Go to checkout ✓ passed (36.5s)
md5: 5f6d47df5841d82aba28bb53e1bd2b50
Click "Place order" and verify the checkout page shows a "Payment mode" section listing "Cash on Delivery".

## Choose cash on delivery ✓ passed (47.1s)
md5: 379f2002dacafed22440b6cbffee7418
Click "Cash on Delivery" and verify the price details show a "COD handling fee" of "₹25.00" and a total payable of "₹2,564.00".

## Confirm the order ✓ passed (40.6s)
md5: 91b5ede54e61528b0b0f6c10a287bec1
Click "Confirm COD order" and verify the page shows "Order confirmed" with a payment mode of "Cash on Delivery" and an order status of "Confirmed - pay on delivery".

Putting it in CI

You get a payment mode test that checks the fee, the arithmetic and the resulting order state, which is the set of things a COD bug actually breaks. It runs in three minutes without anyone handling cash.

Run it alongside the card path rather than instead of it, since the two diverge after the payment selection. Running Kane CLI in CI covers executing several flows per build, and evidence based QA covers what to keep from each run.