HarperFast / HarperFast/integration-testing

Tests: cover remaining runHarperCommand startup-watchdog branches

Open
#10 0 comments 0 reactions 0 assignees View on GitHub
enhancement good first issue
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

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.