# 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.