test(appgen): cover generated-app module loud-failure path#351
Merged
Conversation
PR #350 made moduleSource fail loudly when go list -m cannot determine the main module and the generated app imports app-owned packages, but only the decision heuristic (isLocalModuleImportPath / appHasLocalModuleImports) was unit-tested; the error-propagation path itself was not. Add two integration tests that run outside any Go module (t.Chdir to an empty temp dir, so go list -m fails with a real 'no go.mod' reason): - with an app-owned inline go {} import, moduleSource surfaces 'cannot determine the app Go module' - with no app-owned imports, moduleSource tolerates the failure and still emits a valid generated go.mod Full go test ./... (55 non-example packages) passes.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Closes the one concrete gap left after PR #350 (the fail-loudly fallback hardening, now merged): the
moduleSourceloud-failure path had no test. Only the decision heuristic (isLocalModuleImportPath/appHasLocalModuleImports) was unit-tested; the actual error propagation was unverified.Changes
Two integration tests in
internal/appgen/appgen_test.go. Both run outside any Go module viat.Chdir(t.TempDir()), sogo list -m -jsonfails with a genuine "no go.mod" reason:TestModuleSourceFailsLoudlyWhenAppModuleUndeterminedWithLocalImports— with an app-owned inlinego {}import,moduleSourcesurfacescannot determine the app Go moduleinstead of silently dropping therequire/replace.TestModuleSourceToleratesUndeterminedAppModuleWithoutLocalImports— with no app-owned imports, the samego list -mfailure is tolerated and a valid generatedgo.modis still produced.This pins down both sides of the intentional behavior so neither can regress silently.
Verification
go test ./...across all 55 non-example packages passes (full suite, not just touched packages — closing the earlier "full suite not run" gap).examples/*fail togo buildas before — they are.gwdkdemo projects, not Go mains; pre-existing and unrelated.Deferred items — evaluated, not bugs
While here I re-checked the two "judgment call" items from the gap review and confirmed neither is masked error-handling:
{name}precedence (data wins over route param for a bare name): documented precedence with explicitparam("x")/field("x")overrides; both values are valid. Not a masked error — a hard error would break valid usage.validate_identity,validate_stores); route overlaps viaambiguous_dynamic_route.No behavior change — test + changelog only.