Three of the 30 bug entries exactly as they appear in the kit, so you can judge the level of detail. The other 27 are in the paid download. Spoiler warning: if you want to hunt for the bugs yourself first, download the free app and come back later.
The 30 bugs by area
Validation: 6
Status codes: 5
Authentication: 5
Pagination and search: 5
Calculations: 5
User interface: 4
B01: Registration accepts an email address without a domain
Validation · Severity Major · Priority High
Steps to reproduce
POST /api/auth/register with name "Asha Rao", email "a@b", password "Passw0rd1".
Expected: 400 Bad Request with field "email" and a message that the address is not valid.
Actual: The account is created. The API only checks that the text contains an @.
How to catch it: Send several malformed emails (no domain, no dot, spaces, double @) and assert 400 for each. A boundary table of valid and invalid formats finds this quickly.
Where in the code: src/app.js, register handler (emailOk). Automated in 04-framework/tests/api/validation.spec.ts.
B13: Any signed-in user can read another user's order
Authentication · Severity Critical · Priority High
Expected: 404 Not Found (or 403): you may only see your own orders.
Actual: 200 OK with the other customer's order, including their address and phone number.
How to catch it: Broken object-level authorization: for every endpoint with an id in the path, call it with a valid token belonging to a different user.
Where in the code: src/app.js, order by id handler. Automated in 04-framework/tests/api/auth.spec.ts.
B22: GST is charged on the price before the discount
Expected: Tax is 18% of the discounted amount (₹2,899), which is ₹521.82.
Actual: Tax is 18% of ₹2,999 (₹539.82): the customer is overcharged.
How to catch it: Work out the expected total by hand for a case with a discount and compare every line: subtotal, discount, tax, shipping, total.
Where in the code: src/money.js, totals (taxBase). Automated in 04-framework/tests/api/calculations.spec.ts.
A model interview answer from the guide
“How do you know your tests are good?”
I ran them against a fixed build and against the buggy build. On the fixed build every test passes, so none is wrong. On the buggy build the tests tagged with a bug id fail, so each one catches its bug. A test that cannot fail is useless, and a test that fails on a healthy app is a false alarm. I checked both.
How the bug score works
Every test in the framework is named after the bug it checks, for example [B07] registering returns 201 Created. A test fails when the app is wrong, so a failing [B07] means your suite caught bug B07. One command runs everything and prints the result:
Bugs caught: 30 of 30 (100%)
Caught: B01 B02 B03 ... B30
Not caught: none
No unexpected failures.
Against the fixed build the same command reports 0 caught and no failures, which proves your tests themselves are sound.
