denis-li-20 / restaurant-manager Goto Github PK

https://restaurant-manager-front-end.herokuapp.com/

+ Back-end

Main tools: Node.js, Express, Dotenv, CORS

Test data generators: Faker, Nanoid

CLI tool to run multiple scripts: npm-run-all

PostgreSQL client: pg

Logging and formatting: pino, pino-http, pino-pretty

+ Front-end

Main tools: React, React-dom, React-router, React-router-dom, React-scripts, Axios

End to end testing: @testing-library/jest-dom, @testing-library/react, @testing-library/user-event

+ Reservations

Create new reservations using the web-form Form will auto-validate the inputs and let you know if the data is missing or incorrect

+ Tables

Create new tables which could be used to seat the reservations Form will auto-validate the inputs and let you know if the data is missing or incorrect

+ Search

Search reservations by full mobile number Search reservations by partial mobile number

+ Dashboard

Get the list of reservations and tables for the selected date Switch the date by using the navigation buttons Manage reservations: seat reservation by selecting the table, edit the reservation, or cancel the reservation Manage tables: seat reservation, finish reservation

MacOS

1. Download / Fork-Pull the repository
2. Terminal: npm install
3. Command line: npm install concurrently
4. Create Postgresql database (for instance, using free ElephantSQL.com instance)
5. Update ./back-end/knexfile.js and ./back-end/.env database URLs
6. Terminal: npm run start

1. Set up four new ElephantSQL database instances - development, test, preview, and production - by following the instructions in the "PostgreSQL: Creating & Deleting Databases" checkpoint.
2. After setting up your database instances, connect DBeaver to your new database instances by following the instructions in the "PostgreSQL: Installing DBeaver" checkpoint.

Windows

1. Download / Fork-Pull the repository
2. Remove package.json and rename package_windows.json to package.json
3. Command line: npm install
4. Command line: npm install concurrently
5. Create Postgresql database (for instance, using free ElephantSQL.com instance)
6. Update ./back-end/knexfile.js and ./back-end/.env database URLs
7. Commad line: npm run start

If you want to seed a more extensive testing dataset:

- The tests are meant for the original dataset, some of them will fail if you seed the extended dataset

Reservations

1. Open ./back-end/src/db/seeds/00-reservations.js
2. Uncomment lines 1 - 79
3. Comment lines 82 - 140
4. The script will automatically generate test dataset, line 54 controls the number of records created by the script

Tables

1. Open /back-end/src/db/seeds/01-teables.js
2. Uncomment lines 1 - 29
3. Comment lines 31 - 44
4. The script will generate 18 tables instead of 4

The table below describes the folders in this repository:

The ./back-end folder contains all the code for the backend project.

The table below describes the existing files in the ./back-end folder:

The ./front-end folder contains all the code for the frontend project.

The table below describes the existing files in the ./front-end folder:

This project has unit, integration, and end-to-end (e2e) tests. End-to-end tests use browser automation to interact with the application just like the user does.

Test are split up by user story. You can run the tests for a given user story by running:

npm run test:X where X is the user story number.

Have a look at the following examples:

• npm run test:1 runs all the tests for user story 1 (both frontend and backend).
• npm run test:3:backend runs only the backend tests for user story 3.
• npm run test:3:frontend runs only the frontend tests for user story 3.

Whenever possible, frontend tests will run before backend tests to help you follow outside-in development.

Note When running npm run test:X If the frontend tests fail, the tests will stop before running the backend tests. Remember, you can always run npm run test:X:backend or npm run test:X:frontend to target a specific part of the application.

Since tests take time to run, you might want to consider running only the tests fyou're working on at any given time.

You can run all the tests using the following commands:

• npm test runs all tests.
• npm run test:backend runs all backend tests.
• npm run test:frontend runs all frontend tests.
• npm run test:e2e runs only the end-to-end tests.

If you would like a reminder of which npm scripts are available, run npm run to see a list of available commands.

To help you better understand what might be happening during the end-to-end tests, screenshots are taken at various points in the test.

The screenshots are saved in front-end/.screenshots and you can review them after running the end-to-end tests.

You can use the screenshots to debug your code by rendering additional information on the screen.

As a restaurant manager
I want to create a new reservation when a customer calls
so that I know how many customers will arrive at the restaurant on a given day.

1. The /reservations/new page
   • has the following required and not-nullable fields:
     • First name: <input name="first_name" />
     • Last name: <input name="last_name" />
     • Mobile number: <input name="mobile_number" />
     • Date of reservation: <input name="reservation_date" />
     • Time of reservation: <input name="reservation_time" />
     • Number of people in the party, which must be at least 1 person. <input name="people" />
   • displays a Submit button that, when clicked, saves the new reservation, then displays the /dashboard page for the date of the new reservation
   • displays a Cancel button that, when clicked, returns the user to the previous page
   • displays any error messages returned from the API
2. The /dashboard page
   • lists all reservations for one date only. (E.g. if the URL is /dashboard?date=2035-12-30 then send a GET to /reservations?date=2035-12-30 to list the reservations for that date). The date is defaulted to today, and the reservations are sorted by time.
   • displays next, previous, and today buttons that allow the user to see reservations on other dates
   • displays any error messages returned from the API
3. The /reservations API has the same validations as above and will return 400, along with an informative error message, when a validation error happens.
   • seed the reservations table with the data contained in ./back-end/src/db/seeds/00-reservations.json

As a restaurant manager
I only want to allow reservations to be created on a day when we are open
so that users do not accidentally create a reservation for days when we are closed.

1. The /reservations/new page displays an error message with className="alert alert-danger" if any of the following constraints are violated:
   • The reservation date is a Tuesday as the restaurant is closed on Tuesdays.
   • The reservation date is in the past. Only future reservations are allowed.
2. The /reservations API has the same validations as above and returns 400, along with an informative error message, when a validation error happens.

As a restaurant manager
I only want to allow reservations to be created during business hours, up to 60 minutes before closing
so that users do not accidentally create a reservation for a time we cannot accommodate.

1. The /reservations/new page displays an error message with className="alert alert-danger", if any of the following additional constraints are violated:
   • The reservation time is before 10:30 AM.
   • The reservation time is after 9:30 PM, because the restaurant closes at 10:30 PM and the customer needs to have time to enjoy their meal.
   • The reservation date and time combination is in the past. Only future reservations are allowed. E.g., if it is noon, only allow reservations starting after noon today.
2. The /reservations API has the same validations as above and will return 400, along with an informative error message, when a validation error happens.

As a restaurant manager,
When a customer with an existing reservation arrives at the restaurant
I want to seat (assign) their reservation to a specific table
so that I know which tables are occupied and free.

1. The /tables/new page

   • has the following required and not-nullable fields:
     • Table name: <input name="table_name" />, which must be at least 2 characters long.
     • Capacity: <input name="capacity" />, this is the number of people that can be seated at the table, which must be at least 1 person.
   • displays a Submit button that, when clicked, saves the new table then displays the /dashboard page
   • displays a Cancel button that, when clicked, returns the user to the previous page

2. The /dashboard page will:

   • displays a list of all reservations in one area.
   • each reservation in the list will:
     • Displays a "Seat" button on each reservation.
     • The "Seat" button is a link with an href attribute that equals /reservations/${reservation_id}/seat, so it can be found by the tests.
   • displays a list of all tables, sorted by table_name, in another area of the dashboard
     • Each table displays "Free" or "Occupied" depending on whether a reservation is seated at the table.
     • The "Free" or "Occupied" text has a data-table-id-status=${table.table_id} attribute, so it can be found by the tests.

3. The /reservations/:reservation_id/seat page will

   • have the following required and not-nullable fields:
     • Table number: <select name="table_id" />. The text of each option must be {table.table_name} - {table.capacity} so the tests can find the options.
   • do not seat a reservation with more people than the capacity of the table
   • display a Submit button that, when clicked, assigns the table to the reservation then displays the /dashboard page
   • PUT to /tables/:table_id/seat/ in order to save the table assignment. The body of the request must be { data: { reservation_id: x } } where X is the reservation_id of the reservation being seated. The tests do not check the body returned by this request.
   • display a Cancel button that, when clicked, returns the user to the previous page

4. The tables table must be seeded with the following data:

   • Bar #1 & Bar #2, each with a capacity of 1.
   • #1 & #2, each with a capacity of 6.

5. The /tables API will have the same validations as above and will return 400, along with an informative error message, when a validation error happens.

• if the table capacity is less than the number of people in the reservation, return 400 with an error message.
• if the table is occupied, return 400 with an error message.

As a restaurant manager
I want to free up an occupied table when the guests leave
so that I can seat new guests at that table.

1. The /dashboard page
   • Displays a "Finish" button on each occupied table.
   • the "Finish" button has a data-table-id-finish={table.table_id} attribute, so it can be found by the tests.
   • Clicking the "Finish" button displays the following confirmation: "Is this table ready to seat new guests? This cannot be undone." If the user selects "Ok" the system: - Sends a DELETE request to /tables/:table_id/seat in order to remove the table assignment. The tests do not check the body returned by this request. - The server returns 400 if the table is not occupied. - Refreshes the list of tables to show that the table is now available.
   • Clicking the "Cancel" makes no changes.

Hint The end-to-end test waits for the tables list to be refreshed before checking the free/occupied status of the table, so be sure to send a GET request to /tables to refresh the tables list.

As a restaurant manager
I want a reservation to have a status of either booked, seated, or finished
so that I can see which reservation parties are seated, and finished reservations are hidden from the dashboard.

1. The /dashboard page
   • displays the status of the reservation. The default status is "booked"
     • the status text has a data-reservation-id-status={reservation.reservation_id} attribute, so it can be found by the tests.
   • displays the Seat button only when the reservation status is "booked".
   • clicking the Seat button changes the status to "seated" and hides the Seat button.
   • clicking the Finish button associated with the table changes the reservation status to "finished" and removes the reservation from the dashboard.
   • the status is set by this request: PUT to /reservations/:reservation_id/status with a body of {data: { status: "<new-status>" } } where <new-status> is one of booked, seated, or finished

As a restaurant manager
I want to search for a reservation by phone number (partial or complete)
so that I can quickly access a customer's reservation when they call about their reservation.

1. The /search page
   • Displays a search box <input name="mobile_number" /> that displays the placeholder text: "Enter a customer's phone number"
   • Displays a "Find" button next to the search box.
   • Clicking on the "Find" button submits a request to the server (e.g. GET /reservations?mobile_phone=555-1212).
     • then the system looks for the reservation(s) in the database and displays all matched records on the /search page using the same reservations list component as the /dashboard page.
     • the search page displays all reservations matching the phone number, regardless of status.
   • displays No reservations found if there are no records found after clicking the Find button.

As a restaurant manager
I want to be able to modify a reservation if a customer calls to change or cancel their reservation
so that reservations are accurate and current.

1. The /dashboard and the /search page:
   • Display an "Edit" button next to each reservation
     • Clicking the "Edit" button navigates the user to the /reservations/:reservation_id/edit page
   • the "Edit" button is a link with an href attribute that equals /reservations/${reservation_id}/edit, so it can be found by the tests.
   • Displays a "Cancel" button next to each reservation
   • The Cancel button has a data-reservation-id-cancel={reservation.reservation_id} attribute, so it can be found by the tests.
   • Clicking the "Cancel" button displays the following confirmation: "Do you want to cancel this reservation? This cannot be undone."
     • Clicking "Ok" on the confirmation dialog, sets the reservation status to cancelled, and the results on the page are refreshed.
       • sets the status of the reservation to cancelled using a PUT to /reservations/:reservation_id/status with a body of {data: { status: "cancelled" } }.
     • Clicking "Cancel" on the confirmation dialog makes no changes.
2. The /reservations/:reservation_id/edit page displays the reservation form with the existing reservation data filled in
   • Only reservations with a status of "booked" can be edited.
   • Clicking the "Submit" button saves the reservation, then displays the previous page.
   • Clicking "Cancel" makes no changes, then displays the previous page.