Homework 1

Build a Safety Net for an Inherited System

Run Tartan Tickets, add useful tests, report three defects, fix each one, and add a test that proves each fix.

Onboarding Testing Debugging Maintenance Defect reporting

Release Date Aug 24, 2026

Due Date Sep 7, 2026

Weight 100 pts

Overview

You have inherited Tartan Tickets, a university event-ticketing website where customers create accounts, browse events, pay through TartanPay, and view their order history. It is used to provide ticketing for concerts, guest lectures, theater performances, and athletic events across campus. Behind the scenes, Tartan Tickets relies on a website, an HTTP gateway, several services, a database, and the Mailpit email server to work together.

For the rest of the semester, you are responsible for building, securing, shipping, and operating this system. Your first task is to form a basic understand of the system: how its services work together, which behavior is intentional, and whether its existing tests provide useful evidence.

You should begin by spinning up the complete system on your local machine and exercising the basic functionality on the website by browsing events and buying tickets. Then explore other paths and unusual inputs by writing automated tests. Each test that you write will help to form a safety net that will protect you from unexpected changes in later assignments.

The inherited codebase is known to contain defects. By Checkpoint A, you should identify and report three significant defects with evidence that another person could use to reproduce the problem. After Checkpoint A, you should fix each of your reported defects and accompany each of them with a regression test (a test that fails before the fix and passes afterward).

🎯 Learning Goals

After completing this assignment, you should be able to:

• Run an unfamiliar system made of several connected services from a fresh copy of the repository
• Use tests to investigate and protect important behavior
• Report a defect with clear reasoning and evidence that others can reproduce
• Find and fix the cause of a failure in an inherited codebase
• Maintain one dependable command that runs all required checks

🚩 Checkpoints

Checkpoint	Points	Due	Last accepted
Checkpoint A: Starting Point and Defect Reports	55 pts	Aug 30, 2026	Sep 3, 2026
Checkpoint B: Fixes and Safety Net	45 pts	Sep 7, 2026	Sep 11, 2026

Due and last-accepted times are 11:59 p.m. Eastern Time.

Late Days Carry Across Checkpoints

HW1A and HW1B use the same course-wide late-day balance. Each late day charged for HW1A moves your HW1B due time one day later; staff will record the adjusted due time in Canvas. HW1B's September 10 last-accepted time does not move.

Project Context

Course staff will create a private repository for you to investigate and maintain throughout the semester. Use what you observe in the running system and your understanding of the problem to distinguish defects from feature requests, design preferences, user mistakes, and environment problems.

Requirements

Requirements for Both Checkpoints

The ./scripts/check file is the project's single entry point for running all required automated checks. At each checkpoint, ./scripts/check must:

• Run all provided tests and all tests you have added by that checkpoint
• Run from the repository root inside the Dev Container against the application managed by Docker Compose
• Return an error status (a nonzero exit code) when a check fails and print enough information to identify the failure
• Be repeatable and finish within five minutes

./scripts/check must connect to the application URL specified by TARTAN_BASE_URL, which defaults to http://localhost:8636. Build and start the application before running ./scripts/check. The command may wait for the application to become ready and must leave it running.

Record Your AI-Use Disclosure

Add an ## HW1 heading to DISCLOSURE.md and write your disclosure there. Briefly describe any AI tools you used and how you used them. There is no required format or length. If you did not use AI, say so. At Checkpoint B, update the same entry so it covers all of your HW1 work.

Checkpoint A: Establish the Starting Point

Run the Required Customer Flow

• Start the complete application through the provided Dev Container and Docker Compose configuration
• Complete a customer journey from start to finish: register, open the activation email in Mailpit, activate the account, sign in, browse events, buy a ticket through TartanPay, receive a purchase confirmation, and find the order in order history

Having issues trying to run the system on your machine?

Contact a TA before Checkpoint A with the command, output, and what you tried. If the problem remains, staff will arrange a fallback environment without affecting your grade.

Build a Safety Net

You will write at least five automated tests for HW1: two for Checkpoint A and three new regression tests for Checkpoint B. A test cannot count toward both requirements.

For Checkpoint A, write at least two tests that describe behavior you believe is correct in the inherited system. Every test you add for Checkpoint A must pass against that version of the system and run through ./scripts/check. Do not add the three defect regression tests until after you submit Checkpoint A.

You may add more than two passing tests at Checkpoint A. Report possible defects separately.

Use the test tools and types that best fit the behavior you choose. For example, Vitest works well for testing individual JavaScript or TypeScript units, while Playwright can exercise browser interactions and complete user flows. There is no requirement to use any particular testing tool or framework.

Report Three Defects

File three defect reports using the provided HW1 issue template. The template adds the hw1-defect label that staff use to find your reports. Keep that label on exactly the three reports you want graded; remove it from any draft or duplicate report. For each report, explain the affected behavior and why it matters, the required setup, the steps and inputs that reproduce it, the expected and actual results, your evidence, how to check the fix, and why you believe it is a defect.

Each report must cover a different problem; include multiple symptoms of one problem in the same report. Use course support for setup failures and user mistakes. Treat cosmetic preferences and requests for new behavior as product feedback. Before sharing evidence, remove credentials, tokens, personal data, and other sensitive application data. Finding the underlying cause and proposing a fix are optional at Checkpoint A.

Request Staff Approval

When a defect report is ready for review, add a comment that says @cmu-devops/course-staff Ready for HW1 review. Staff will respond within 48 hours to approve the report or explain what you must revise. If staff request changes, update the report and add the review-request comment again. If you do not receive a response within 48 hours, contact course staff on Slack and include a link to the issue.

An approval confirms that the report describes a reproducible, consequential defect that counts for HW1. It does not confirm a suspected cause or proposed repair. All three reports must receive approval before you submit Checkpoint B.

You May Fix More Than Three Defects

You are welcome to report and fix additional defects. Improving the codebase now will help because you will work with it throughout the semester. Keep the hw1-defect label on only the three reports you want graded. Track each additional defect in its own issue without that label, and fix it in a separate pull request.

Prepare and Submit Checkpoint A

1. Confirm that exactly three issues in your repository have the hw1-defect label and that you requested staff review on each one.
2. Add your HW1 entry to DISCLOSURE.md and run ./scripts/check.
3. Commit every file needed to run and grade your work. All three reported defects must still be present in this commit.
4. Record a video of roughly three minutes or less. Show the exact Checkpoint A commit, the Dev Container, the running services, the complete customer journey, and a successful run of ./scripts/check. Narration is optional.
5. In the HW1A Canvas text box, paste the exact commit URL and embed the recording with Canvas's media tool.

Create this commit before you begin fixing any reported defect. Do not amend or replace it after you record the video. Staff will find the three labeled issues and review the tests changed in your submitted commit, so you do not need to repeat them in Canvas.

Checkpoint B: Fix and Protect the System

Fix the Reported Defects

Find and fix the underlying cause of each approved defect. Put each fix in a separate pull request that contains only the work for that defect. In each pull-request description, write Closes #ISSUE-NUMBER for the one defect report that it fixes, and name the test that catches the defect. Each pull request must close a different one of your three HW1 defect reports when it merges into main. Your fixes and tests must cover the exact example in the report and other inputs that expose the same problem.

After Checkpoint A, add three new regression tests: one for each of your three approved defects. Add each regression test in the pull request that fixes its defect. Although these tests are not part of Checkpoint A, staff must be able to run each one against your Checkpoint A version and see it fail because of the defect, then run it after your fix and see it pass. Preserve the Checkpoint A commit and issue history.

Prepare and Submit Checkpoint B

1. Merge all three pull requests.
2. Update your HW1 entry in DISCLOSURE.md to cover the complete assignment.
3. Run ./scripts/check.
4. Commit the updated disclosure. This Checkpoint B commit must contain all three merged fixes.
5. Submit the exact commit URL in HW1B on Canvas. Do not submit a branch or pull-request URL.

Leave the Complete System in Working Order

Keep the existing ways that users and services interact with the system, along with the Docker Compose commands, Dev Container, and database structure, working as before. Limit changes to the work needed for the reported defects, tests, and ./scripts/check.

Additional Evaluation

Staff will test your submitted Checkpoint B commit in a fresh copy of the system using several relevant inputs.

Submission and Deliverables

Complete each checklist and use the corresponding Canvas submission.

HW1A: Starting Point and Defect Reports

Due Sunday, August 30 at 11:59 pm ET.

Last accepted Thursday, September 3 at 11:59 pm ET.

• Complete the customer journey and add at least two automated tests that protect different important behaviors.
• Report three different defects using the HW1 issue template. Each report must meet the requirements below and keep the hw1-defect label.
• Request staff approval for each defect report.
• Add an HW1 entry to DISCLOSURE.md.
• Create a Checkpoint A commit. All three reported defects must still be present in this version.
• Record a video of roughly three minutes or less that shows this commit, the customer journey, and a successful run of ./scripts/check.
• In HW1A on Canvas, paste the exact Checkpoint A commit URL and embed the recording.

Open HW1A in Canvas→

HW1B: Fixes and Safety Net

Due Monday, September 7 at 11:59 pm ET.

Last accepted Friday, September 11 at 11:59 pm ET.

• Fix each approved defect in its own pull request, add one new regression test for each defect, and merge all three pull requests.
• Keep your Checkpoint A commit and history.
• Link each pull request to the defect it fixes with Closes #ISSUE-NUMBER in the pull-request description.
• Update the HW1 entry in DISCLOSURE.md.
• Create a Checkpoint B commit that includes all three fixes. Confirm that ./scripts/check passes.
• In HW1B on Canvas, submit the exact Checkpoint B commit URL.

Open HW1B in Canvas→

Grading

The assignment is worth 100 points.

HW1A — Checkpoint A55 pts

• The Checkpoint A commit has an HW1 entry in DISCLOSURE.md covering work through Checkpoint A. Staff can run this version using only committed files and the provided tools. Credentials and secrets remain outside the repository.5 pts
• The recording shows the complete required customer journey and a successful run of `./scripts/check` at the submitted commit.5 pts
• At the submitted commit, `./scripts/check` meets the requirements for both checkpoints and runs all provided tests and tests added by Checkpoint A.5 pts
• At least two tests added by Checkpoint A pass in the submitted Checkpoint A version and protect different important behaviors.10 pts
• The lower-numbered issue labeled `hw1-defect` describes a reproducible staff-approved defect. It removes sensitive information, supports the expected behavior, and explains how to check the fix.10 pts
• The middle-numbered issue labeled `hw1-defect` describes a different reproducible staff-approved defect. It removes sensitive information, supports the expected behavior, and explains how to check the fix.10 pts
• The higher-numbered issue labeled `hw1-defect` describes a third reproducible staff-approved defect. It removes sensitive information, supports the expected behavior, and explains how to check the fix.10 pts

HW1B — Checkpoint B45 pts

• The Checkpoint B commit keeps the Checkpoint A history and contains all three fixes. Each recorded defect issue links to its merged pull request, and the HW1 entry in DISCLOSURE.md covers the complete assignment.5 pts
• The first fix corrects the reported defect and similar cases with a change limited to that defect that fits the existing design.5 pts
• The second fix corrects the reported defect and similar cases with a change limited to that defect that fits the existing design.5 pts
• The third fix corrects the reported defect and similar cases with a change limited to that defect that fits the existing design.5 pts
• Three regression tests added after Checkpoint A each catch a different defect in the Checkpoint A version, pass in the Checkpoint B version, and protect the corrected behavior across similar cases.15 pts
• At Checkpoint B, the existing ways that users and services interact with the system, along with its database structure, continue to work as before.5 pts
• At the submitted commit, `./scripts/check` meets the requirements for both checkpoints and runs all provided tests, Checkpoint A tests, and tests for all three fixes.5 pts