Testing Terms for Vibe Coding

Write clear acceptance criteria for the itinerary feature: saving shows the trip, refresh keeps it, and invalid dates explain how to fix them.

Write a failed-login test case so another person can use the same account and steps and see the same result.

Add unit tests for price calculation: 100 gets 20 off, 99 does not, and external payment must not participate.

Test that submitting a registration form sends correct fields, the API saves them, and the page shows server errors.

The backend renamed a field in the response, and our frontend crashed on deploy. How can we catch this automatically on commit?

Like a real user, create an itinerary from the travel home page, save it, reopen it, and confirm the confirmation page shows that same trip.

After a new version reaches testing, first check that home opens, login works, and the core API responds; if one fails, do not start full regression.

After changing tax rules, rerun payment, coupons, and order confirmation as well as the new rule to ensure working checkout was not broken.

Do not only report “90% coverage”; also show whether the high-risk path combining payment failure and a coupon was actually tested.

When testing an order failure message, use a controllable payment test double that returns “payment rejected” instead of depending on the real payment service every time.

Prepare fixed user and product data for the order test, and create it before every run and clean it after so the next run starts identically.

Run the same commit five times: it sometimes passes and sometimes times out. Check waiting conditions and shared accounts first; do not hide red with endless retries.

Before the event, simulate many real checkout users and show how latency, throughput, and error rate behave at the target load.