152 lines
2.8 KiB
Markdown
152 lines
2.8 KiB
Markdown
# 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
|
|
|
|
```bash
|
|
git ls-remote git@gitea.jig.com.hk:jig-software/trest.git
|
|
```
|
|
|
|
If using Yarn with private Gitea Packages, verify package access:
|
|
|
|
```bash
|
|
export JIG_SOFTWARE_GITEA_DEPLOYMENT_TOKEN="<your-gitea-token>"
|
|
yarn npm info @jig-software/trest
|
|
```
|
|
|
|
Optional check (if supported by your Gitea npm endpoint):
|
|
|
|
```bash
|
|
yarn npm whoami --scope jig-software
|
|
```
|
|
|
|
2. Fresh clone and dependency install
|
|
|
|
```bash
|
|
git clone git@gitea.jig.com.hk:jig-software/trest.git
|
|
cd trest
|
|
# run the package-manager-specific install command
|
|
```
|
|
|
|
For package-consumer verification:
|
|
|
|
```bash
|
|
yarn add @jig-software/trest
|
|
```
|
|
|
|
If npm package publishing is not enabled, verify direct git installation instead:
|
|
|
|
```bash
|
|
yarn add trest@git+ssh://git@gitea.jig.com.hk/jig-software/trest.git
|
|
```
|
|
|
|
3. Baseline tests
|
|
|
|
```bash
|
|
# 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:
|
|
|
|
```text
|
|
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
|
|
|
|
```text
|
|
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.
|