marco-trest-test/docs/trest-test-plan.md

TREST Test Plan (First Week)

Use this checklist to validate trest behavior while you learn the package.

Scope

• Confirm installability and importability.
• Confirm one core workflow works end-to-end.
• Capture edge-case behavior.
• Produce notes useful for maintainers and future joiners.

Test Environment Matrix

Start small, then expand.

• OS: Linux (current machine)
• Runtime: project default version
• Branch/tag: team-approved target

If needed, expand to:

• Alternate runtime version
• CI environment parity run

Phase 1: Setup Validation

1. Access check

git ls-remote git@gitea.jig.com.hk:jig-software/trest.git

If using Yarn with private Gitea Packages, verify package access:

export JIG_SOFTWARE_GITEA_DEPLOYMENT_TOKEN="<your-gitea-token>"
yarn npm info @jig-software/trest

Optional check (if supported by your Gitea npm endpoint):

yarn npm whoami --scope jig-software

2. Fresh clone and dependency install

git clone git@gitea.jig.com.hk:jig-software/trest.git
cd trest
# run the package-manager-specific install command

For package-consumer verification:

yarn add @jig-software/trest

If npm package publishing is not enabled, verify direct git installation instead:

yarn add trest@git+ssh://git@gitea.jig.com.hk/jig-software/trest.git

3. Baseline tests

# run project test command, examples:
# npm test
# pytest -q
# cargo test
# go test ./...

Record:

• Exact command
• Runtime version
• Pass/fail summary
• Any flaky tests

Phase 2: API Smoke Tests

Pick the top 1-3 public APIs used by other services.

For each API, test:

• Happy path input
• Empty/null-ish input
• Invalid type/format input
• Boundary values

Template:

API name:
Input:
Expected:
Actual:
Status: PASS/FAIL
Notes:

Phase 3: Integration-Style Check

Build a tiny consumer app and verify:

• Package install from private source
• Import path correctness
• Typical call sequence
• Error handling contract

Keep the script minimal and reproducible.

Phase 4: Non-Functional Checks

• Performance sanity: does a basic call return in expected time?
• Logging: are errors actionable?
• Determinism: same input gives same output (if expected behavior)

Defect Reporting Format

When filing issues, include:

• Environment (OS, runtime version)
• trest commit hash or version
• Repro steps
• Expected vs actual
• Logs/stack trace
• Minimal repro snippet

Daily Notes Template

Date:
Goal:
Commands run:
Results:
Questions:
Blockers:
Next step:

Exit Criteria

• Setup is reproducible from a clean machine.
• Core APIs validated with at least happy path + one edge case.
• At least one consumer-style integration tested.
• Issues documented with clear repro steps.
• Personal onboarding notes shared with team.