Test favoriting an item and that it survives a reload

The flow under test

Three levels of evidence separate a button that changed its label from a feature that works, and the test asserts each one.

• The control responds - the button text changes from Favorite to Favorited.
• The list agrees - the favorites page reports 1 favorite and names the listing.
• The state persisted - after a reload, the count and the listing are both still there.

Only the third proves anything reached storage. The first two pass happily against state that exists only in the current page session, which is precisely the bug this class of feature tends to have.

The test file

The favorite button is referenced by the text a shopper sees, including its heart glyph, and the assertion checks the changed label rather than a class name or an aria attribute.

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

# Etsi 5.2: Shop search and favorite

Catalog objective: search a shop, favorite an item, and verify it in the favorites list.
Key assertion: the favorited item persists after reload.

## Search for a shop
Type "KilnAndClay" into the search box and verify the results show "2 listings" including "Hand-thrown Speckled Mug".

## Favorite an item
Click the "♡ Favorite" button on "Hand-thrown Speckled Mug" and verify the button now reads "♥ Favorited".

## Open the favorites list
Click the "Favorites" link in the header and verify the favorites page shows "1 favorite" and lists "Hand-thrown Speckled Mug".

## Confirm it survives a reload
Reload the page and verify the favorites page still shows "1 favorite" and still lists "Hand-thrown Speckled Mug".

The reload is written as a plain instruction. Run the test with:

kane-cli testmd run tests/etsy/shop-search-favorite_test.md

The run

Four passes in 155 seconds. Favoriting the item was the cheapest step at 25.2 seconds, since it is a single click and a label check on a page that is already open.

---
test: ../shop-search-favorite_test.md
status: passed
started: 2026-09-15T10:07:46.555Z
duration_s: 155
session_id: 4df5b154-6293-444c-b6a1-dab25db2d74c
---

# Etsi 5.2: Shop search and favorite - Result

## Search for a shop ✓ passed (39.9s)
md5: e680abb81b7b31a10d165647752c87f1
Type "KilnAndClay" into the search box and verify the results show "2 listings" including "Hand-thrown Speckled Mug".

## Favorite an item ✓ passed (25.2s)
md5: c6aa4c419d465cf09f1ae92f56470b3d
Click the "♡ Favorite" button on "Hand-thrown Speckled Mug" and verify the button now reads "♥ Favorited".

## Open the favorites list ✓ passed (46.2s)
md5: 32ba6f2e40fa9c75efe2a547cbeafe79
Click the "Favorites" link in the header and verify the favorites page shows "1 favorite" and lists "Hand-thrown Speckled Mug".

## Confirm it survives a reload ✓ passed (39.5s)
md5: bb03a1d732bbf0f85add9d7010989bde
Reload the page and verify the favorites page still shows "1 favorite" and still lists "Hand-thrown Speckled Mug".

The reload step cost 39.5 seconds, roughly the same as the initial navigation, which is the honest price of proving persistence. It is worth paying once per feature rather than not at all.

Reading the evidence

What you get is a test that distinguishes a working favorites feature from a convincing one. The reload step is reusable for any feature backed by storage: saved searches, carts, recently viewed, comparison lists.

The same persistence question comes up constantly in agent-written front end code, where in-memory state is a frequent shortcut. Verifying agent-written code covers that loop, and the Kane CLI introduction has the setup if you are starting from scratch.