Test search to product page with Kane CLI

The flow under test

A search flow is really three separate contracts stacked on top of each other, and a test that only checks the last one tells you very little about where the break is.

• The query returns the right set - typing "headset" has to produce a result count and a matching title, not an empty state or a stale cache.
• The result opens the right product - the click has to land on the product detail page for that exact item, with the brand and price intact.
• The product is actually purchasable - stock status and the Add to Cart and Buy Now buttons have to render, or the traffic search sent you goes nowhere.

Kane CLI checks all three in one run, and marks which of the three failed rather than reporting a single red cross at the end. For the wider picture on writing checks this way, see test.md, the plain English test format.

The test file

The whole test is a markdown file. Front matter sets the starting URL and a step ceiling, then each H2 is one step written the way you would describe it to a colleague.

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

# ShopKart 1.1: Search to product page

Catalog objective: search for wireless earbuds and open the product page.
Key assertion: product page matches the searched item.

## Search the storefront
Type "headset" into the "Search ShopKart" box and press Enter, then verify the results page shows "1 result for "headset"" and a result titled "Wireless Gaming Headset 7.1".

## Open the product
Click the result "Wireless Gaming Headset 7.1" and verify the product page shows the title "Wireless Gaming Headset 7.1", the brand "Aurex" and the price "$79.99".

## Confirm the buy box is usable
Verify the buy box shows "In Stock" and both an "Add to Cart" and a "Buy Now" button are present.

Nothing in that file names a CSS class, an XPath or a data-testid. The quoted strings are what a person reads on screen, so the file survives a front end refactor that renames every selector underneath it. Run it with the testmd runner:

kane-cli testmd run tests/amazon/search-to-product_test.md

The run

Kane CLI opens Chrome, resolves each sentence against the live page, and writes a Result.md next to the test. Every step carries its own duration and an md5 of the instruction, so a changed step is visible in the diff.

---
test: ../search-to-product_test.md
status: passed
started: 2026-09-15T09:06:21.425Z
duration_s: 162
session_id: bea0a7db-adcf-433b-a6af-53da637f8207
---

# ShopKart 1.1: Search to product page - Result

## Search the storefront ✓ passed (67.2s)
md5: 7e5493f1aa4180d16c796ae459b0c826
Type "headset" into the "Search ShopKart" box and press Enter, then verify the results page shows "1 result for "headset"" and a result titled "Wireless Gaming Headset 7.1".

## Open the product ✓ passed (46.6s)
md5: 5ed016c9ec7eada792df19b01d1df0e8
Click the result "Wireless Gaming Headset 7.1" and verify the product page shows the title "Wireless Gaming Headset 7.1", the brand "Aurex" and the price "$79.99".

## Confirm the buy box is usable ✓ passed (44.1s)
md5: c897d5274360389a6dba8858a154dca8
Verify the buy box shows "In Stock" and both an "Add to Cart" and a "Buy Now" button are present.

The slowest step is the first one at 67.2 seconds, because it includes browser startup and the initial page load. That is worth knowing before anyone reads the per step timings as a performance measurement.

Reading the evidence

What you have at the end is a search regression check that reads like documentation and needs no framework, no page object and no selector maintenance. It runs the same way on a laptop and in a pipeline.

The natural next step is to wire it into a build so it runs on every deploy of the storefront. Running Kane CLI in CI covers the exit codes and the headless flags, and the GitHub Actions setup has a working workflow file.