HarperFast / HarperFast/integration-testing
Tests: cover remaining runHarperCommand startup-watchdog branches
- Dominant language
- TypeScript
- Stars
- 1
- Forks
- 0
- Avg merge
- 17d 7h
- Merged PRs (30d)
- 2
Description
## Summary
Follow-up from #8 / #9. The lifecycle race fixes added the repo's first tests (`test/`), covering the port helpers, the startup watchdog's main paths, and `killHarper`'s signal logic. A few `runHarperCommand` branches remain uncovered and are cheap to test — the fixture-script harness in `test/harperLifecycle.test.ts` (spawning short `.cjs` scripts via `harperBinPath`) already supports them, so no real Harper is needed.
## Branches to cover
- [ ] **Completion marker split across stream chunks** — a fixture that emits `successfully started` across two `stdout.write` calls/chunks should still be detected as ready (verifies the `stdout.includes(...)` accumulation, not just per-chunk matching).
- [ ] **Spawn-error path** — when the runtime/binary can't spawn (e.g. a non-existent/non-executable `harperBinPath`), `runHarperCommand` rejects *and* closes the `stdout.log`/`stderr.log` write streams (no leaked FDs). `'exit'` never fires on a failed spawn.
- [ ] **CI-aware absolute cap default** — `DEFAULT_STARTUP_MAX_MS` resolves to 300s when `process.env.CI` is set and 120s otherwise (the `IS_CI` branch).
- [ ] **Post-readiness log streaming** — after the ready marker, continued process output is still written to the `logDir` files and is *not* re-accumulated into the returned `startupOutput` snapshot.
## Notes
These are functional tests that spawn `node` child processes — same style as the existing `test/` suite. Low effort; good first issue.
---
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Contributor guide
Assessment
This issue has not been assessed yet.