W6: Packaging, Testing Baseline, and “Definition of Done”

W6: Packaging, Testing Baseline, and “Definition of Done”

What you’re doing

You stop shipping “it works on my laptop”.

W6 is where your projects stop being personal experiments and start looking like real engineering.

If you skip this, you’ll build a pile of code that nobody trusts (including you).

Time: 4–6 hours
Output: a repeatable packaging/run setup, basic tests that actually matter, and a hard quality gate (“done means done”)

The promise (what you’ll have by the end)

By the end of W6 you will have:

• One command to run your service
• One command to run tests
• A minimal “release checklist” you follow every time
• A definition of done that prevents half-baked shipping
• A repo that a stranger can clone and run

Your new rule

If it’s not reproducible, it’s not real.

Reproducible means:

• clean install works
• tests pass
• docs explain it
• outputs are predictable

Step-by-step checklist

1) Make running boring (one command)

Pick one standard:

• `make dev` / `make test`
• or `npm scripts` (if it’s JS)
• or `uv` / `poetry` / `pip-tools` + a documented run command

Goal: a stranger runs it in 5 minutes.

2) Lock dependencies (no surprises)

You need deterministic installs:

• requirements.txt / lockfile / pyproject with pinned versions

If dependency updates break you randomly, you will quit.

3) Add a minimal test suite (the “don’t break it” tests)

Not 100 tests. The right 5–10 tests.

Minimum:

• health endpoint test
• one “happy path” test for your main endpoint
• one validation failure test (bad input)
• one test that checks schema/rules don’t change silently (snapshot-ish)

4) Add basic CI (optional but powerful)

If GitHub Actions exists in the repo, add:

• run tests on PR
• fail fast

If you don’t want CI yet, at least keep it as a TODO checklist.

5) Write a REAL README

README must include:

• what the project is
• how to run
• how to test
• example requests (curl)
• “known limitations” (so you control expectations)

Most people skip this. That’s why their “portfolio” looks fake.

6) Define your “Definition of Done” (print it and follow it)

Here is the quality gate:

DONE = all true:

• ✅ Code is pushed to GitHub (not local)
• ✅ Project runs with one command
• ✅ Tests run with one command and pass
• ✅ README is updated (run/test/examples)
• ✅ There is at least one demo artifact (screenshot, sample input/output)
• ✅ There is a short “What I learned / next improvements” note

If any is missing — it’s not done.

Deliverables (you must ship these)

Deliverable A — Packaging / run flow

• One documented run command
• Deterministic dependencies

Deliverable B — Testing baseline

• At least 4 meaningful tests
• Tests pass locally

Deliverable C — Definition of Done doc

• A short checklist file exists (e.g., `docs/definition-of-done.md`)

Deliverable D — README upgraded

• Run / Test / Examples
• Known limitations section

Common traps (don’t do this)

No. First make local reproducible. Containers come after you have stability.

• Trap 1: “I’ll add Docker and Kubernetes now.”

Tests are cheaper than debugging production-style chaos later.

• Trap 2: “Tests are boring.”

README later means never.

• Trap 3: “README later.”

Quick self-check (2 minutes)

Answer yes/no:

• Can a stranger run this project in 5 minutes?
• Can I run tests in one command?
• Do I have tests for happy path + failure path?
• Is my Definition of Done written and followed?
• Is the repo portfolio-ready?

If any “no” — fix it this week.

Next module preview (W7–W8)

Next we start Phase 2: SAP Extraction Patterns.
OData, files, exports — and how to build extraction that doesn’t explode in real life.