# Manual Test Cases – Room Booking Module (UI)

This document describes manual UI test cases for the Room Booking feature at **EMS → Bookings** (`/ems/bookings`). Perform each test in order where dependencies exist.

---

## Prerequisites

- Backend server running (e.g. `node dashboard/server.js` or `npm run start:server`).
- Frontend running (e.g. `npm start`).
- Logged in as an admin (or role with access to EMS/Bookings).
- At least one **Hotel** and one **Room type** exist for the active competition (create via Hotel Management if needed).
- Optional: some **Participants** (non-Athlete, not soft-deleted) for allocation tests.

---

## Test 1: Bookings page loads and shows empty state when no room units exist

**Goal:** Confirm the page loads and shows the correct message when the selected room type has no room units.

**Steps:**

1. In the app sidebar, click **Bookings** (or go to `/ems/bookings`).
2. Confirm the page title is **"Rooms information"**.
3. In the top bar, confirm you see:
   - A **Hotel** dropdown.
   - A **Room type** dropdown (if the selected hotel has room types).
4. Select a **Hotel** that has at least one room type.
5. Select a **Room type** that has **no room units** (e.g. one created before the booking feature, or never initialized).
6. Confirm you see the message:  
   **"No room units found for this room type. Units are created when rooms are added or capacity is increased."**
7. Confirm you see the **"Initialize room units"** button.

**Expected:** Page loads, dropdowns work, empty-state message and button are visible.

---

## Test 2: Initialize room units (backfill)

**Goal:** Create room units for a room type that has none.

**Steps:**

1. Stay on **Bookings** with a **Hotel** and **Room type** selected that show the empty-state message (see Test 1).
2. Click **"Initialize room units"**.
3. Wait for the request to complete (button may show "Initializing…").
4. Confirm the empty-state message and button **disappear**.
5. Confirm a **grid** appears with:
   - A **Room** column on the left with one row per room unit (labels "1", "2", … up to the room type’s `no_of_rooms`).
   - A **Beds** value per row (from the room type’s `bed_count`).
   - **Date columns** (e.g. 12 columns) with day and date headers.
   - **Available** cells (e.g. price like "0$") for each room unit × date.
6. Confirm **date navigation** arrows (previous / next week) are visible in the Room column header.

**Expected:** After clicking Initialize, the grid appears with one row per unit and available cells; no errors.

---

## Test 3: Hotel and room type selection

**Goal:** Verify dropdowns filter the grid correctly.

**Steps:**

1. On **Bookings**, ensure at least two hotels have room types (with room units initialized).
2. Select **Hotel A**.
3. Select a **Room type** for Hotel A.
4. Confirm the grid shows only room units for that room type (row count = that type’s `no_of_rooms`).
5. Change the **Room type** to another type for the same hotel (if any).
6. Confirm the grid updates to the new type’s units.
7. Change the **Hotel** to **Hotel B**.
8. Confirm the **Room type** dropdown options update to Hotel B’s types.
9. Select a room type for Hotel B and confirm the grid shows that type’s units.

**Expected:** Changing hotel/room type updates the grid to the correct room units; no stale data.

---

## Test 4: Date navigation

**Goal:** Verify moving the date range updates the grid.

**Steps:**

1. On **Bookings**, select a hotel and room type that show the grid.
2. Note the **date range** in the column headers (e.g. first and last visible date).
3. Click the **left (previous)** arrow in the Room column header.
4. Confirm the date columns move **back** by 7 days (or the configured step).
5. Click the **right (next)** arrow several times.
6. Confirm the date columns move **forward** and the grid still renders (no crash, no blank columns).

**Expected:** Date range changes with the arrows; grid stays stable.

---

## Test 5: Room unit label editing

**Goal:** Change a room unit’s label and see it persist.

**Steps:**

1. On **Bookings**, select a hotel and room type that show the grid with at least one room unit.
2. In the **Room** column, find a row with a room label (e.g. "1").
3. Click the **pencil (edit)** icon next to the room label.
4. Confirm an **inline edit** appears: text input with the current label and check/cancel (or similar) actions.
5. Change the label to a new value (e.g. "12b" or "A1").
6. Click the **check (save)** icon (or press Enter if supported).
7. Confirm the label in the grid updates to the new value.
8. **Optional:** Refresh the page, reselect the same hotel/room type, and confirm the label is still the new value.

**Expected:** Label can be edited inline and persists after save and refresh.

**Cancel path:**

9. Click the pencil on another row, type a new label, then click **cancel** (X).
10. Confirm the label reverts to the previous value and is not saved.

---

## Test 6: Create a booking (allocation modal) – empty cell

**Goal:** Allocate a participant to an empty room unit × date cell.

**Steps:**

1. On **Bookings**, select a hotel and room type with room units and ensure you have at least one **participant** (non-Athlete, not deleted).
2. Find an **empty (available)** cell for one room unit and one date (e.g. price shown, no name).
3. **Click** the empty cell.
4. Confirm the **Allocation modal** opens with:
   - Title like "Allocate Room" or similar.
   - Room label and date.
   - **Participant** dropdown or search.
   - **Allocation type** (e.g. Standard, Private, Athlete).
   - **Guests** (number, max = room’s bed count).
   - **Price** (optional).
   - Cancel and **Allocate** (or Save) buttons.
5. In the modal:
   - Select a **participant** from the list.
   - Leave or set **Allocation type** (e.g. Standard).
   - Set **Guests** to 1 (or allowed max).
   - Optionally set **Price**.
6. Click **Allocate** (or Save).
7. Confirm the modal **closes**.
8. Confirm the **same cell** now shows a **booked** state:
   - Participant name.
   - Allocation type / status.
   - Guest count and/or price.
   - Same styling as other booked cells (e.g. green for standard, different for private).

**Expected:** Empty cell opens allocation modal; after submitting, the cell shows the new booking and modal closes.

---

## Test 7: Create booking – validation (bed limit)

**Goal:** Cannot exceed bed count when allocating.

**Steps:**

1. Use a room type with **bed_count = 1** and at least one room unit. (Edit room type in Hotel Management if needed.)
2. On **Bookings**, create a booking in an empty cell for that room unit and date (complete Test 6 once).
3. Click **another empty cell** for the **same** room unit and **same** date (if the UI allows multiple bookings per cell; otherwise use a room with bed_count = 2 and create one booking first).
4. Open the allocation modal and try to add a **second** participant with **Guests = 1** (so total would exceed 1).
5. Click **Allocate**.
6. Confirm an **error message** appears (e.g. "Bed limit exceeded" or similar) and the booking is **not** created; modal stays open or closes with message.

**Expected:** Backend/frontend validation prevents exceeding bed count; user sees a clear error.

---

## Test 8: View and edit existing booking (booked cell)

**Goal:** Open a booked cell and edit the booking.

**Steps:**

1. On **Bookings**, ensure at least one cell is **booked** (from Test 6).
2. **Click** the **booked** cell (same room unit and date).
3. Confirm a **Booking details / edit** view or modal opens showing:
   - Participant name.
   - Date and room label.
   - Allocation type, guest count, price (if shown).
   - **Edit** and **Cancel** (or Delete) booking actions.
4. Click **Edit** (or equivalent).
5. Change **Allocation type** (e.g. from Standard to Private) and/or **Guests** or **Price**.
6. Click **Save** (or Update).
7. Confirm the modal/view closes and the **cell** still shows the same participant but with the **updated** type/guests/price (e.g. "Private" or new guest count).

**Expected:** Booked cell opens; edit applies and grid updates.

---

## Test 9: Cancel (delete) booking

**Goal:** Remove a booking from a cell.

**Steps:**

1. On **Bookings**, click a **booked** cell to open the booking menu/modal.
2. Click **Cancel** (or **Cancel booking** / **Delete**).
3. If a confirmation appears ("Cancel this booking?" or similar), confirm it.
4. Confirm the modal closes and the **cell** becomes **empty (available)** again (e.g. shows price only).
5. Confirm no errors in the UI or console.

**Expected:** Booking is removed and cell shows available state.

---

## Test 10: Participant list in allocation modal (exclusions)

**Goal:** Allocation modal does not list Athletes or deleted participants.

**Steps:**

1. Ensure you have at least one participant in the **Athletes** group and one **non-Athlete** participant (and optionally one soft-deleted participant).
2. On **Bookings**, click an **empty** cell to open the **Allocation** modal.
3. Open the **Participant** dropdown or list.
4. Confirm **Athlete** participants are **not** listed (or are clearly excluded).
5. Confirm **deleted** participants are **not** listed.
6. Confirm **non-deleted, non-Athlete** participants **are** listed.
7. Use the **search** (if present): type a participant name and confirm the list filters correctly.

**Expected:** Only eligible participants appear; search works.

---

## Test 11: Multiple bookings per cell (if supported)

**Goal:** When bed_count > 1, multiple participants can share the same room unit × date.

**Steps:**

1. Use a room type with **bed_count ≥ 2** and at least one room unit.
2. On **Bookings**, click an **empty** cell for that unit and a date.
3. Create the **first** booking (participant A, 1 guest). Confirm the cell shows booked.
4. Click the **same** cell again.
5. Confirm the booking menu shows the **existing** booking(s) and may allow **adding** another (or the UI allows adding via the same modal).
6. Add a **second** participant (participant B, 1 guest) for the same room unit and date.
7. Confirm the cell shows **both** participants (or "2 guests" / similar) and does not exceed bed_count.

**Expected:** Multiple bookings per cell work up to bed_count; grid reflects total guests.

---

## Test 12: Error handling and messaging

**Goal:** Clear feedback when something fails.

**Steps:**

1. **Initialize with no room:** Select a room type that has **no** `hotel_id` (or use an invalid room). Try **Initialize room units** if shown. Confirm an error message appears (e.g. "Room has no hotel_id" or 400/404) and no crash.
2. **Duplicate participant same cell:** Try to create a second booking for the **same** participant, **same** room unit, **same** date. Confirm an error (e.g. "already booked") and no duplicate.
3. **Network/backend down:** With dev tools, throttle network or stop the backend. Try Initialize or Create booking. Confirm the UI shows an error (e.g. "Failed to..." or network error) and does not leave the user with no feedback.

**Expected:** Errors are shown as messages or in UI; no silent failures.

---

## Summary checklist

| #  | Test area                    | Pass / Fail |
|----|------------------------------|-------------|
| 1  | Page load & empty state      |             |
| 2  | Initialize room units        |             |
| 3  | Hotel / room type selection |             |
| 4  | Date navigation              |             |
| 5  | Room label editing           |             |
| 6  | Create booking (empty cell)  |             |
| 7  | Bed limit validation         |             |
| 8  | Edit existing booking        |             |
| 9  | Cancel booking               |             |
| 10 | Participant list exclusions  |             |
| 11 | Multiple bookings per cell   |             |
| 12 | Error handling               |             |

---

**Notes:**

- If your app uses different labels (e.g. "Allocate" vs "Assign"), adjust steps to match the UI.
- For Test 11, if the product does not support multiple bookings per cell, mark N/A and skip.
- Run tests in a dev or test environment; avoid production for destructive or data-changing steps.