Stop rescheduling from regressing

Raised by: Marco (Booking API owner) · Priority: High · Component: Booking API

Goal

Rescheduling a booking (PATCH /bookings/{id}) has no tests, and it has broken in production three times this quarter. Each time someone "cleaned up" the code, every test stayed green, and Office Ops found out from angry users. We want tests that pin down how rescheduling behaves, so the next change that breaks it fails CI instead.

You are writing tests, not changing the app. Put them in tests/ (for example tests/test_reschedule.py). The shared fixtures in tests/conftest.py (client, book) are there for you to use; conftest.py itself can't be changed. The README explains the API and how tests talk to it.

Requirements

Cover the rescheduling contract as a user of the API sees it:

• Moving to free time works. The response and a later GET /bookings/{id} show the new times; the booking keeps its id, room, title and organizer.
• You can't move into someone else's booking. Overlapping another booking in the same room is rejected with 409 {"detail": "Room already booked"}, and the booking stays where it was. Bookings that only touch (one ends exactly when the other starts) and bookings in other rooms are not conflicts.
• A booking can be moved or extended within its own slot. Making 09:00–10:00 into 09:00–10:30 or 09:30–10:30 is fine: a booking never conflicts with itself.
• Partial updates keep the other field. Sending only start keeps the current end; sending only end keeps the current start.
• Invalid ranges are rejected with 422, including ones that only become invalid once combined with the time you didn't send (an end before the start, a zero-length booking, a booking that crosses midnight). A rejected change leaves the booking untouched.
• Unknown booking id → 404.
• The old slot becomes free. After a move, the original time can be booked by someone else and shows as free in GET /rooms/{room_id}/availability.

Acceptance

• We run your tests against the current code: they must all pass. A test that fails on correct code makes the whole suite useless, and scores zero.
• We then run them against several realistic broken versions of the rescheduling code. Each broken version counts as caught when at least one of your tests fails on it. Your score is the share caught.
• Only test files count; changes to the app code are ignored when grading.