Test a best offer flow and its pending state

Failure modes in this flow

Offer flows fail in three ways, and each needs its own assertion rather than a single end-state check.

• The boundary is not enforced - an offer at the asking price is accepted when it should be refused.
• The amount is not carried - the offer sends, but at a different value than the one typed.
• The state is wrong - the offer lands as accepted or expired rather than awaiting the seller.

The test checks the boundary at exactly the asking price, $219 against a $219 listing, rather than at some obviously invalid value. A rule implemented with the wrong comparison operator passes a test that offers $500 and fails this one.

Writing the objective

The rejection assertion quotes the error string in full. A generic validation message and a correctly targeted one are different bugs, and only the exact text distinguishes them.

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

# eBid 6.3: Best Offer flow

Catalog objective: submit a best offer below the asking price and verify the pending state.
Key assertion: the offer shows as sent with the correct amount.

## Open a listing that accepts offers
Click "50mm f/1.8 Prime Lens" and verify the listing shows a price of "$219.00" and a "Send Best Offer" button.

## Reject an offer at or above asking
Type "219" into the offer field, click "Send Best Offer", and verify an error appears reading "A Best Offer must be below the asking price."

## Send a lower offer
Clear the offer field, type "180", click "Send Best Offer", and verify the page shows "Offer sent" with an amount of "$180.00".

## Confirm the pending state
Click "My eBid" and verify the Best Offers list shows "50mm f/1.8 Prime Lens" at "$180.00" with status "Pending seller response".

The final step leaves the listing and checks the account page, because an offer that appears to send and never reaches the seller is the failure that costs a sale. Run the test with:

kane-cli testmd run tests/ebay/best-offer_test.md

Running it locally

Four passes, evenly spread. Opening the listing was the slowest step at 49.2 seconds since it carries the initial page load.

---
test: ../best-offer_test.md
status: passed
started: 2026-09-15T10:19:44.434Z
duration_s: 158
session_id: 5d9be3d7-581b-4b00-b0db-96da29d812ab
---

# eBid 6.3: Best Offer flow - Result

## Open a listing that accepts offers ✓ passed (49.2s)
md5: 31cad0dfc862beb1c222541bc9f3cb06
Click "50mm f/1.8 Prime Lens" and verify the listing shows a price of "$219.00" and a "Send Best Offer" button.

## Reject an offer at or above asking ✓ passed (30.3s)
md5: d7e8d3ccff8e30b6d5e38361d921dca6
Type "219" into the offer field, click "Send Best Offer", and verify an error appears reading "A Best Offer must be below the asking price."

## Send a lower offer ✓ passed (39.9s)
md5: 599ee8cf3c85bea76f87b6d1aa6de060
Clear the offer field, type "180", click "Send Best Offer", and verify the page shows "Offer sent" with an amount of "$180.00".

## Confirm the pending state ✓ passed (36.8s)
md5: 9d1bf563f863a297e297fd723a4e01ce
Click "My eBid" and verify the Best Offers list shows "50mm f/1.8 Prime Lens" at "$180.00" with status "Pending seller response".

Putting it in CI

The outcome is a negotiation test that pins the business rule, the amount and the resulting state, which together are what a best offer feature promises.

Offer and bid flows differ mainly in their validation rule, so one file adapts into the other by changing the rule and the expected strings. Test case generation handles that kind of variant well, and running flows asynchronously covers executing a family of them at once.