W06 Assignment: Testing Web Services
Overview
- Purpose: Add repeatable automated tests that verify important Kizuna Rail API behavior.
- Task: Complete one testing feature set and submit the required deliverables.
During the previous weeks, your team added database models, authentication, authorization, write operations, pagination, searching, and filtering. This week, you will add automated tests that give your team confidence that those features continue to work.
Each person will take responsibility for one API area. You will test the real Express routes with Vitest and Supertest. The tests will use the temporary MongoDB database configured for the project, so create, update, and delete tests cannot damage the deployed database.
Team-based work continues
Coordinate feature-set ownership with your teammates. Complete each task through a GitHub issue and pull request, and post each pull request in Microsoft Teams when it is ready for review. Do not push your work directly to main.
Assignment Requirements
- Choose one feature set from the list below. Each team member should own a different feature set.
- Complete every testing task in your selected feature set.
- Create a separate GitHub issue and pull request for each numbered task.
- Use Vitest and Supertest to test the real Express endpoints.
- Use only the temporary test database. Do not run automated tests against the deployed database.
- Make every test independent so it can run by itself or with the complete test suite.
- Run the complete test suite and ESLint before opening each pull request.
- Create a short walk-through video for each pull request.
- Share each completed pull request in your Microsoft Teams channel when it is ready for review.
- Upload a completed reflection document to Canvas.
Feature Sets
Each person must complete one feature set. A five-person team should assign one feature set to each person. If your team has fewer than five people, start with the first three feature sets and assign #4–5 only as needed. Make sure to communicate your assignments in Microsoft Teams.
Feature Set 1: Trips API
Add automated tests for /api/trips and its related trip endpoints.
- Read tests: Test the endpoint that returns all trips and the endpoint that returns one trip. Verify successful status codes, important response fields, and known seeded trip data. Include a not-found test for a trip id that does not exist.
- Write tests: Test creating, updating, and deleting trips through the API. Verify the response status and body, and query the temporary database to prove that each operation made the expected change. Include the authentication or administrator role needed by the real routes.
- Pagination and search tests: Test the pagination, region filter, season filter, and keyword search behavior added in Week 05. Verify returned records and pagination metadata. Include at least one request that returns no matches and one request for a page containing fewer than the maximum number of results.
Feature Set 2: Users API
Add automated tests for /api/users and its related user endpoints.
- Read tests: Test the endpoint that returns users and the endpoint that returns one user. Verify the behavior for an administrator and a standard signed-in user. Confirm that API responses do not expose password hashes or other private authentication data.
- Write tests: Test the existing user creation or registration behavior and the API operations that update and delete users. Verify authorized and unauthorized behavior, response status codes, and the resulting records in the temporary database.
- Pagination and search tests: Test user pagination, role filtering, and keyword search across display names, usernames, or email addresses. Verify the result data and pagination metadata, including a request that returns no matches.
Feature Set 3: Bookings API
Add automated tests for /api/bookings and its related booking endpoints.
- Read tests: Test the endpoint that returns bookings and the endpoint that returns one booking. Verify the difference between administrator access and standard-user access. A standard user should only receive bookings they are allowed to view.
- Write tests: Test creating, updating, and deleting bookings. Use valid seeded trip, schedule, and ticket-class data. Verify the HTTP response and query the temporary database to prove the booking was created, changed, or removed. Include the authentication and ownership behavior required by the real routes.
- Pagination and filter tests: Test booking pagination, ticket-class filtering, and booking-date filtering added in Week 05. Verify the returned bookings and pagination metadata. Include requests that cover multiple pages and no matching results.
Feature Set 4: Stations API and Trip Relationships
Add automated tests for /api/stations and the relationship between stations and trips. New station write operations are not required.
- Station read tests: Test the endpoint that returns all stations and the endpoint that returns one station. Verify successful status codes, response fields, and known seeded station data. Include a not-found test for a station id that does not exist.
- Trip relationship tests: Test how trips use station data. Verify that the origin and destination station references for a known trip match real station records. Test the API response that provides this related information and verify that it returns the stations connected to the selected trip.
Feature Set 5: Schedules API and Trip Relationships
Add automated tests for /api/schedules and the relationship between schedules and trips. New schedule write operations are not required.
- Schedule read tests: Test the endpoint that returns all schedules and the endpoint that returns one schedule. Verify successful status codes, response fields, and known seeded schedule data. Include a not-found test for a schedule id that does not exist.
- Trip relationship tests: Test how schedules are connected to trips. Verify that a known schedule references the correct trip. Test the API behavior that retrieves schedules for a selected trip, and confirm that it returns only schedules connected to that trip.
Testing Expectations
Use the provided testing infrastructure
The project is configured with Vitest, Supertest, and MongoDB Memory Server. The test setup starts a temporary database, clears it, and restores known starter data before each test. Use this shared setup instead of creating another database connection system.
Every testing task should follow these expectations:
- Send requests through the real Express application with Supertest.
- Check the expected HTTP status code and important response-body fields.
- For create, update, and delete operations, query the temporary database to verify the saved result.
- Use seeded records found by stable values instead of copying generated MongoDB ids into test files.
- Test authentication, authorization, or ownership when those rules are part of the endpoint.
- Do not make one test depend on data created by another test.
- Use descriptive test names that identify the situation and expected behavior.
- Do not change correct application requirements only to make a failing test pass.
Pull Request Workflow
Complete each numbered task in your feature set as a separate issue and pull request. This keeps the work easier to review and reduces conflicts between teammates.
Determine the test plan and create GitHub issues
Before writing the tests, inspect the real routes and decide what behavior each test must prove. Record the plan in the GitHub issue.
- List the HTTP methods and URLs that will be tested.
- Identify the seeded records or test accounts the tests will use.
- List the expected status codes and important response fields.
- Identify any authentication, role, or ownership requirements.
- For write operations, describe the database result that will be verified.
Implement the tests
- Create a branch for the issue.
- Add the automated tests for that task.
- Run the new test file by itself while developing.
- Run the complete test suite with
npm test. - Run ESLint and correct any reported errors.
- Confirm that no test uses the database connection from
.env.
Using AI while coding
You may use AI to help write or understand tests. You are responsible for checking every expectation against the real API behavior. You should understand each test clearly enough to explain what it proves and why its setup is safe.
Create a walk-through video
Record a short video for each pull request. Each video should be about two minutes long and no longer than three minutes.
- Explain which endpoint behavior the tests cover.
- Run the tests and show that they pass.
- Show the important test code and explain the setup, request, and expectations.
- Explain at least one decision you made when choosing what to test.
Create the pull request
Open a pull request that references the related GitHub issue. Summarize the tests that were added, include the test command and result, and link to the walk-through video. Post the pull request in Microsoft Teams when it is ready for review.
Pull requests are required
Create one pull request for each numbered task in your feature set. Feature Sets 1–3 require three pull requests. Feature Sets 4–5 require two pull requests. Do not push code directly to main.
Prepare for Week 07 Code Review
Your teammates will review the Week 06 pull requests at the beginning of Week 07. Make every pull request ready for review before the end of this assignment.
- The pull request connects to its GitHub issue.
- The description explains what behavior the tests prove.
- The complete test suite and ESLint pass.
- The pull request includes a link to the walk-through video.
- The pull request is posted in Microsoft Teams as ready for review.
Reflection
After completing all tasks in your feature set, reflect on what the tests proved and what you learned.
Do not use AI for this reflection
The purpose of this document is to help you reflect on your own work and decisions. Write the reflection in your own words.
- Download the Week 06 reflection template.
- Answer each question in your own words.
- Include links to every pull request completed for your feature set.
- Save the completed document as a
.txtor.mdfile. - Upload the completed reflection document to Canvas.
Deliverables Checklist
- You completed every task in one testing feature set.
- You created a GitHub issue and pull request for each task.
- Each pull request includes a walk-through video.
- The complete automated test suite and ESLint pass.
- You shared each pull request in Microsoft Teams.
- You uploaded your completed reflection to Canvas.
Other Links:
- Return to: Week Overview | Course Home