The assignment
Two contributors must add a ticket summary to the repair-desk project without losing existing behavior. One implements a business operation; the other reviews it and adds a regression test. The deliverable includes an issue, a small branch, test evidence, a review, and a release note. Solo learners can take both roles sequentially, but should describe the exercise honestly rather than invent a second reviewer.
Start with the previous lessons' tickets.py and test_tickets.py. Keep app.py and index.html if you completed the full-stack lesson. You need Python 3.9 or newer and Git. Remote collaboration is optional: every code and merge command below runs locally. A hosted repository adds pull requests and CI; it does not replace understanding the underlying branch and test state.
Refresh Git workflows and experiment in the Git sandbox before changing valuable history. This project uses a new practice repository, so there is no reason to force-push an existing team's branch.
Requirements and contribution data model
The requested operation, summary(), returns a dictionary with exactly two integer counts, open and resolved. Empty databases return zeros for both. Resolving one ticket changes the counts without changing their sum. No schema change or HTTP endpoint is included in this feature; explicitly documenting scope prevents a reviewer from expecting a dashboard that the patch does not deliver.
Use a lightweight contribution record. An issue contains a problem statement, acceptance criteria, exclusions, and owner. A branch represents one change. A commit records a coherent implementation step. A review records findings and their resolution. A release record identifies the merged commit and verification evidence. Store issue and review text as Markdown locally if you do not use a hosting provider.
A ticket remains the same database entity as before: integer identifier, title, status. Do not create a stored summary table. Counts are derived data, and a second persisted copy would require synchronization every time a ticket changes. The acceptance criteria should capture observable behavior rather than prescribing a particular SQL statement.
Milestone 1: establish a reproducible baseline
From the exercise directory, initialize a fresh repository. If it is already a practice repository, skip initialization and work from its current clean branch. Check the status before staging anything.
git init -b main
printf 'tickets.db\n*.db-journal\n*.db-wal\n*.db-shm\n__pycache__/\n.venv/\n' > .gitignore
python3 -m unittest discover -v
git status --short
git add .gitignore tickets.py test_tickets.py
git commit -m "Add tested repair ticket business layer"
Git needs an author identity to create commits. If yours is not configured, set repository-local values using your real identity; the following prompts avoid a pretend author:
read -r -p 'Commit author name: ' author_name
read -r -p 'Commit author email: ' author_email
git config user.name "$author_name"
git config user.email "$author_email"
Run those prompts in Bash (bash starts it), then repeat the commit if it previously failed. Ignoring databases prevents accidental publication of local records; it does not remove files already tracked. Inspect git ls-files before sharing. Stage the optional browser files in a separate baseline commit if they are part of your exercise.
Write issue-summary.md in the following form, replacing neither the criteria nor scope with vague promises:
# Ticket counts for a future desk overview
Problem: volunteers need to know how many tickets remain open.
Acceptance:
- summary() returns open and resolved integer counts.
- An empty desk reports both counts as zero.
- Creating then resolving a ticket moves one count to the other.
- Existing business tests continue to pass.
Scope: business module and unit tests only; no new route or UI.
Owner: the contributor taking the implementation role.
Evidence: unittest output and the final commit identifier.
Assign an actual contributor in the hosted issue or your local record. Discuss ambiguous criteria before implementation. For example, “total tickets” might mean all historical tickets or only active tickets; agreeing on the returned keys now is cheaper than changing clients later.
Milestone 2: contribute a focused patch
Create the branch, then add this complete method inside TicketStore in tickets.py. Match indentation with its existing methods. One grouped query produces a consistent count snapshot for this operation. Filling missing statuses with zero keeps the response shape stable.
git switch -c feature/ticket-summary
def summary(self):
counts = {"open": 0, "resolved": 0}
with closing(self.connect()) as db:
rows = db.execute(
"SELECT status, COUNT(*) AS count FROM tickets GROUP BY status"
).fetchall()
for row in rows:
counts[row["status"]] = row["count"]
return counts
Add these methods inside the existing TicketTests class. They exercise the contract at empty, populated, and transitioned states rather than checking implementation details such as the exact SQL string.
def test_empty_summary(self):
self.assertEqual(self.store.summary(), {"open": 0, "resolved": 0})
def test_summary_tracks_resolution(self):
first = self.store.create("Repair fan")
self.store.create("Repair toaster")
self.assertEqual(self.store.summary(), {"open": 2, "resolved": 0})
self.store.resolve(first["id"])
self.assertEqual(self.store.summary(), {"open": 1, "resolved": 1})
python3 -m unittest discover -v
git diff --check
git diff
git add tickets.py test_tickets.py
git commit -m "Count open and resolved tickets"
git log -1 --oneline
Expect seven tests. Record the commit identifier in the issue evidence. A focused diff lets the reviewer trace every new line to an acceptance criterion. Avoid mixing unrelated formatting, dependency upgrades, or generated files into this change.
Milestone 3: review from the other side
For hosted collaboration, create an empty GitHub repository and use its displayed remote URL with git remote add origin followed by that URL. Push main with git push -u origin main, then push the feature branch with git push -u origin feature/ticket-summary. In GitHub, open a pull request targeting main. Link the issue, describe the returned counts, and include the test command and result. Request review from the actual teammate. The reviewer uses the Files changed view to leave specific comments, then submits an approval or request for changes. Merge through the pull request after required checks pass; the local merge commands below are the alternative for an offline exercise.
The reviewer first runs the tests, then reads the patch against the issue. Ask whether both keys always exist, whether counts are numbers, and whether resolved tickets can be double-counted. Request changes with a reproducible example and a reason, such as “the empty desk loses the resolved key, so consumers cannot rely on the contract.”
Have the reviewer add this regression test to the branch, either through an authorized hosted contribution or a normal local edit while role-playing:
def test_summary_after_repeated_resolution(self):
ticket = self.store.create("Repair radio")
self.store.resolve(ticket["id"])
self.store.resolve(ticket["id"])
self.assertEqual(self.store.summary(), {"open": 0, "resolved": 1})
Run tests again and commit the regression separately. Write review-summary.md with the examined commit, reproduced commands, findings, and final disposition. Do not call a change approved merely because tests are green. Review also checks scope, naming, security implications, and whether the tests would fail for a plausible incorrect implementation.
For a deliberate failure drill, temporarily change the initial resolved count to one. The empty-summary test must fail. Restore the correct value before committing. This demonstrates that the suite detects a real contract violation. If working concurrently, fetch and merge the updated base branch before final review; resolve conflicts by understanding both changes, then rerun the suite.
Milestone 4: automate and merge
For GitHub CI, save this complete file as .github/workflows/tests.yml. The official Python workflow guide documents interpreter setup. This job uses no application secrets and only needs repository read access.
name: Python tests
on: [push, pull_request]
permissions:
contents: read
jobs:
tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v6
- uses: actions/setup-python@v5
with:
python-version: '3.12'
- run: python -m unittest discover -v
- run: git diff --check
Version tags are readable exercise defaults. GitHub's secure use reference recommends full commit SHA pinning for immutable action versions. Before production adoption, resolve trusted release SHAs and establish an update process. Never interpolate an untrusted issue title directly into a shell command, and do not grant deployment credentials to untrusted pull-request code.
Commit the workflow and the recorded issue/review if you want them tracked. Hosted teams should configure required checks and reviews using branch protection; availability depends on repository visibility and account plan. Locally, complete the merge explicitly:
python3 -m unittest discover -v
git switch main
git merge --no-ff feature/ticket-summary -m "Merge reviewed ticket summary"
python3 -m unittest discover -v
git log -1 --oneline
Expect eight tests after the reviewer contribution. If Git reports a dirty working tree, commit or deliberately preserve your changes before switching; do not erase them just to make a command succeed. The Git merge reference explains merge and abort behavior.
Release, security, and interview review
This feature ships as a library change. No deployment is required to prove its acceptance criteria. A future service release should record the deployed commit, run a smoke check, and keep a rollback plan. Reverting code does not reverse database changes; here the schema stayed stable, making rollback simpler.
Render preview environments are a provider-specific option for hosted review. Do not assume previews contain production data or that their services are free. Configure isolated synthetic data and examine resource costs and lifecycle settings before enabling them. The local SQLite demo still needs durable storage and a production server before public use; see deployment.
Treat aggregate counts as potentially sensitive once tickets belong to real people or organizations. A future summary endpoint must apply the same verified ownership scope as listing. CI passing cannot prove authorization or safe secret handling. Review authentication when that scope becomes real.
Use a ten-point rubric: two for precise acceptance criteria, two for a focused implementation, two for meaningful tests, two for actionable review evidence, and two for a traceable merge and release plan. Interview followups: why derive counts instead of storing them? How would you review a failing CI run that passes locally? What happens if the base branch changes after approval? How would you roll back a release with a migration? Ground each answer in an artifact from this exercise, including a failure you deliberately reproduced.
Continue on this track
Use the runnable module from the backend project. The optional browser and transport adapter come from the full-stack project.