Testing/CI/tooling consistency (#9,#20,#21,#22,#23,#28) (#59)

Co-authored-by: claude <claude@jpaul.io>
Co-committed-by: claude <claude@jpaul.io>

modules/14-continuous-integration/README.md

@@ -78,8 +78,8 @@ Almost every CI configuration, on every forge, is the same four moves:
 4. **Run the checks** — lint, then test. Any check that exits non-zero fails the whole run.
 
 That last point is the load-bearing one. CI's entire enforcement mechanism is the **exit code**.
-Every tool you'd run in a terminal returns 0 for success and non-zero for failure. `pytest` exits
-non-zero if a test fails. `ruff check` exits non-zero if it finds a lint problem. CI runs your
+Every tool you'd run in a terminal returns 0 for success and non-zero for failure. `python -m
+unittest` exits non-zero if a test fails. `ruff check` exits non-zero if it finds a lint problem. CI runs your
 commands and watches those exit codes; one failure turns the run red. You're not learning a new
 testing system — you're wiring the tools you already have to a trigger.
 
@@ -125,18 +125,19 @@ jobs:
         with:
           python-version: "3.12"
       - name: Install tools
-        run: pip install pytest ruff
+        run: pip install ruff
       - name: Lint
         run: ruff check .
       - name: Test
-        run: pytest -q
+        run: python -m unittest
 ```
 
 Reading it top to bottom: `on:` is the trigger (push and pull request). `runs-on:` picks the clean
 machine. The `steps:` are the four moves — checkout, set up Python, install the tools, then the two
 checks. `uses:` pulls in a pre-built action (someone else's reusable step); `run:` is just a shell
 command. The linter runs first because it's cheap; the tests run last because they're the
-expensive, decisive check.
+expensive, decisive check. Only the linter needs a `pip install` here — the tests run on Python's
+standard-library `unittest` runner from Module 13, so there's nothing to install for them.
 
 This file lives *in the repo*, committed and versioned like everything else. That's deliberate and
 on-thesis: your pipeline is code, it's reviewed as a diff in a PR (Module 10), and a teammate or an
@@ -151,9 +152,9 @@ When CI goes red, the skill is triage, and it's fast once you know the shape:
 2. **The first red step is the cause.** Steps run in order and stop at the first failure; everything
    after it is skipped, not broken. Don't get distracted by the skipped steps.
 3. **Read that step's log.** It's the same output the tool prints in your terminal — a failing
-   `pytest` assertion, a `ruff` finding with a file and line number. CI didn't invent a new error
+   `unittest` assertion, a `ruff` finding with a file and line number. CI didn't invent a new error
    format; it's showing you the command's own output.
-4. **Reproduce it locally.** Run the exact command from the failed step (`pytest -q` or
+4. **Reproduce it locally.** Run the exact command from the failed step (`python -m unittest` or
    `ruff check .`) on your machine. It will fail the same way, because CI ran the same command. Fix
    it locally, confirm it's green locally, push again.
 
@@ -225,14 +226,21 @@ your machine first.
 
    ```bash
    cd ~/workflow-course/tasks-app
-   pip install pytest ruff
-   pytest -q          # should report all tests passing
-   ruff check .       # should report no issues (or fix what it flags)
+   pip install ruff
+   python -m unittest   # should report all tests passing
+   ruff check .         # should report no issues (or fix what it flags)
    ```
 
    If both are clean locally, CI will be green. If not, fix it here — it's faster than waiting on a
    runner.
 
+   > **If `pip install` is refused** with "externally-managed-environment" (PEP 668 — common on
+   > recent Debian/Ubuntu and Homebrew Python), install into a per-project virtual environment
+   > instead: `python3 -m venv .venv && source .venv/bin/activate` (Windows:
+   > `.venv\Scripts\activate`), then re-run `pip install ruff`. Only the linter needs installing — the
+   > stdlib `unittest` runner needs nothing. (`pipx` or `pip install --break-system-packages` also
+   > work; a venv is the clean default.)
+
 ### Part B — Add the workflow and watch it pass
 
 2. Put the workflow where your forge looks for it:
@@ -288,7 +296,7 @@ and watch CI stop it.
    bad one, instead of rewriting history other people may have pulled.
 
    ```bash
-   pytest -q          # fails locally too — same command, same failure
+   python -m unittest # fails locally too — same command, same failure
    git revert HEAD    # new commit that undoes "Simplify pending()" (Module 12)
    git push           # CI re-runs on the fixed code and goes green again
    ```
@@ -371,5 +379,6 @@ Re-check at build time:
 - [ ] **Forge UI labels.** The tab names in the lab ("Actions," "CI/CD," "Pipelines") and the
       workflow file locations (`.github/workflows/`, `.gitlab-ci.yml`, `.forgejo/`, `.gitea/`) match
       what the current forge versions actually use.
-- [ ] **Tool names.** The example linter and test runner (`ruff`, `pytest`) are current, installable,
-      and still behave as described — or swap in the equivalents the rest of the course uses.
+- [ ] **Tool names.** The example linter (`ruff`) is current, installable, and still behaves as
+      described — or swap in the equivalent the rest of the course uses. (The test runner is Python's
+      standard-library `unittest`, which ships with Python — no install, nothing to drift.)