Skip to content

feat(cmd): never auto-run the test entrypoint; add wippy test#349

Open
skhaz wants to merge 2 commits into
mainfrom
feat/run-require-entrypoint
Open

feat(cmd): never auto-run the test entrypoint; add wippy test#349
skhaz wants to merge 2 commits into
mainfrom
feat/run-require-entrypoint

Conversation

@skhaz

@skhaz skhaz commented Jun 15, 2026

Copy link
Copy Markdown
Member

Why

wippy run <hub-module> could silently run a module's test entrypoint. For
kickside/kickside the only command-enabled entry is wippy/test's runner, so
wippy run kickside/kickside ran the test suite ("Running Tests / No tests found")
and exited instead of running the app.

What

A run/test selection mode threaded through the run flow:

  • wippy run never selects the entrypoint named test. It auto-selects a
    non-test entrypoint (a main wins; otherwise the single non-test one), errors
    listing them when several non-test entrypoints exist without a main, and
    boots the app and keeps it running when a module has no non-test entrypoint.
    Explicit wippy run test is refused (points to wippy test).
  • wippy test [module|file.wapp] — new top-level command that runs only
    the test entrypoint; errors no test entrypoint found if none.
  • The local server path (wippy run / wippy run -c, no positional) is unchanged.

Testing

  • go test -race ./cmd/... green; golangci-lint v2.8.0 0 issues.
  • TestSelectPackCommand (16 cases, both modes) + runPackEntries integration tests
    (no-entrypoint runs-as-server; test-mode error; run-mode unknown-command).
  • Gremlins mutation on run_pack.go: 100% efficacy (0 surviving covered mutants).
  • E2E vs the real hub module:
    • wippy run kickside/kickside → boots the app, stays running, serves :8085
      (HTTP 200), runs no tests.
    • wippy test kickside/kickside → runs the test entrypoint.

@skhaz skhaz requested a review from wolfy-j June 15, 2026 16:16
Why:
`wippy run <hub-module>` could silently run a module's test entrypoint —
kickside/kickside's only command is wippy/test's runner — so "running the
app" ran its tests and exited instead of starting the app.

What:
Thread a run/test selection mode through the run flow. `wippy run` now
excludes the entrypoint named "test" and auto-selects a non-test entrypoint
(a `main` wins; a single non-test otherwise); it errors listing them when
several non-test entrypoints exist without a `main`, and boots the app and
keeps it running when a module has no non-test entrypoint. Explicit
`wippy run test` is refused. A new top-level `wippy test [module]` runs only
the test entrypoint.
@skhaz skhaz force-pushed the feat/run-require-entrypoint branch from f482172 to 4c782fa Compare June 15, 2026 16:34
Why:
`wippy run`/`wippy test` distinguished the test entrypoint with a hardcoded
`testCommandName = "test"` and a runMode enum, special-casing the literal name in
two divergent selection paths. The magic string does not scale to further
run-like commands and forces the CLI to compensate rather than read intent.

What:
Entrypoints now declare `meta.command.use_case` (default "run"); `wippy test`
targets the "test" use case. A single canonical pair, collectCommands +
selectEntrypoint, drives both the lockfile and pack flows, filtering by declared
use case and deriving the cross-use-case hint from the entry's own meta. The
runMode enum, testCommandName, resolveCommandToEntry, and the name-based
exclusion are removed; bare `wippy run` still boots without executing an
entrypoint. The test runner gains `use_case: test`, and the app test harness
scripts move from the now-rejected `wippy run test` to `wippy test`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant