test: split e2e tests and add go-zero integration tests

[spencercjh]

Summary

• Split e2e_test.go into framework-specific test files for better organization
• Add go-zero framework integration tests

Test Plan

• Run e2e tests for go-zero
• Run e2e tests for Spring Boot (Maven/Gradle)
• Verify error handling tests

🤖 Generated with Claude Code

[qodo-code-review]

Review Summary by Qodo

Split e2e tests into framework-specific files and add go-zero tests

🧪 Tests

Walkthroughs

Description

• Split monolithic e2e test file into framework-specific test files
• Added go-zero framework integration tests with detection and generation
• Extracted error handling and mock provider into separate test files
• Improved test organization and maintainability

Diagram

flowchart LR
  A["e2e_test.go<br/>monolithic"] -->|split| B["spring_maven_test.go"]
  A -->|split| C["spring_gradle_test.go"]
  A -->|split| D["gozero_test.go"]
  A -->|split| E["error_test.go"]
  A -->|split| F["mock_provider_test.go"]
  B -->|Maven tests| G["Framework-specific<br/>test suite"]
  C -->|Gradle tests| G
  D -->|Go-zero tests| G
  E -->|Error handling| G
  F -->|Shared utilities| G

Loading

File Changes

1. integration-tests/spring_maven_test.go Refactoring +0/-109

Cleaned up Maven-specific tests

• Removed Gradle Spring Boot test (moved to separate file)
• Removed error handling test (moved to error_test.go)
• Removed mock provider implementation (moved to mock_provider_test.go)
• Removed unused imports for executor and provider packages

integration-tests/spring_maven_test.go

---

2. integration-tests/spring_gradle_test.go 🧪 Tests +67/-0

New Gradle Spring Boot e2e tests

• New file containing Gradle Spring Boot project tests
• Implements TestE2E_GradleSpringBoot_Generate for Gradle wrapper detection
• Tests project detection, spec generation, and validation workflow
• Uses 5-minute timeout for Gradle build operations

integration-tests/spring_gradle_test.go

---

3. integration-tests/gozero_test.go 🧪 Tests +177/-0

New go-zero framework e2e tests

• New file with comprehensive go-zero framework integration tests
• Implements TestE2E_GoZero_Generate for full workflow testing
• Implements TestE2E_GoZero_Detect for project detection verification
• Implements TestE2E_GoZero_NoGoctl for graceful error handling

integration-tests/gozero_test.go

---

View more (2)

4. integration-tests/error_test.go 🧪 Tests +47/-0

New error handling e2e tests

• New file dedicated to error handling tests
• Implements TestE2E_ErrorHandling_CommandNotFound test
• Tests executor behavior when command is not found
• Verifies CommandNotFoundError type assertion

integration-tests/error_test.go

---

5. integration-tests/mock_provider_test.go 🧪 Tests +29/-0

New shared mock provider utility

• New file containing shared mock provider implementation
• Defines countingMockProvider struct for tracking LLM call counts
• Implements provider.Provider interface for test usage
• Provides configurable mock responses for enrichment testing

integration-tests/mock_provider_test.go

---

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (3) 📘 Rule violations (0) 📎 Requirement gaps (0)

1. HasGoctl field missing ☑ 🐞 Bug ✓ Correctness

Description

integration-tests/gozero_test.go references patchResult.HasGoctl, but gozero.PatchResult defines
GoctlAvailable instead. This is a compile-time error that prevents e2e tests from building.

Code

integration-tests/gozero_test.go[R63-72]

+	// Step 2: Patch (verify goctl availability)
+	patcher := gozero.NewPatcher()
+	patchResult, err := patcher.Patch(projectPath)
+	if err != nil {
+		t.Fatalf("Failed to patch project: %v", err)
+	}
+
+	if !patchResult.HasGoctl {
+		t.Skip("goctl not found in PATH, skipping generation test")
+	}

Evidence

The new test expects PatchResult.HasGoctl, but the implementation exposes PatchResult.GoctlAvailable
(no HasGoctl field), so the test cannot compile.

integration-tests/gozero_test.go[63-74]
internal/extractor/gozero/patcher.go[34-38]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`integration-tests/gozero_test.go` uses `patchResult.HasGoctl`, but `gozero.PatchResult` exposes `GoctlAvailable`. This causes a compilation failure under the `e2e` build tag.
## Issue Context
The patcher implementation (`internal/extractor/gozero/patcher.go`) defines:
- `PatchResult.GoctlAvailable`
- `PatchResult.GoctlVersion`
## Fix Focus Areas
- integration-tests/gozero_test.go[63-75]
- integration-tests/gozero_test.go[148-157]
- internal/extractor/gozero/patcher.go[34-38]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. No-goctl path mishandled ☑ 🐞 Bug ⛯ Reliability

Description

The new go-zero e2e tests call patcher.Patch() and t.Fatalf on error, but patcher.Patch() returns
an error (nil result) when goctl is not installed. This makes the tests fail in environments without
goctl rather than skipping or asserting the expected generator error.

Code

integration-tests/gozero_test.go[R148-153]

+	// Check if goctl is available
+	patcher := gozero.NewPatcher()
+	patchResult, err := patcher.Patch(projectPath)
+	if err != nil {
+		t.Fatalf("Failed to check goctl: %v", err)
+	}

Evidence

Patcher.Patch returns nil, error when goctl isn’t found, but the tests treat any Patch error as
fatal. Also, detector already computes gozero.Info.HasGoctl, which is what generator checks to
decide whether to error.

integration-tests/gozero_test.go[148-157]
internal/extractor/gozero/patcher.go[52-68]
internal/extractor/gozero/detector.go[92-100]
internal/extractor/gozero/generator.go[148-152]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
`gozero_test.go` assumes `patcher.Patch()` is a non-failing probe for goctl availability, but `Patch()` returns an error when goctl is missing. This makes e2e tests fail on machines without goctl, instead of skipping or validating the intended error behavior.
## Issue Context
- Detector already sets `gozero.Info.HasGoctl`.
- Generator checks `info.HasGoctl` and returns a clear error if false.
## Fix Focus Areas
- integration-tests/gozero_test.go[63-75]
- integration-tests/gozero_test.go[140-176]
- internal/extractor/gozero/patcher.go[43-68]
- internal/extractor/gozero/detector.go[92-100]
- internal/extractor/gozero/generator.go[148-152]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Type check doesn’t fail ☑ 🐞 Bug ✓ Correctness

Description

The new error-handling e2e test intends to verify CommandNotFoundError, but it only logs when the
type assertion fails. This can let regressions pass undetected.

Code

integration-tests/error_test.go[R43-46]

+	// Verify it's a CommandNotFoundError
+	if _, ok := errors.AsType[*executor.CommandNotFoundError](err); !ok {
+		t.Logf("Got error type %T: %v", err, err)
+	}

Evidence

The executor returns a specific CommandNotFoundError for missing commands, but the test doesn’t fail
if it receives a different type, reducing test effectiveness.

integration-tests/error_test.go[43-46]
internal/executor/executor.go[103-110]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The e2e error handling test logs when the returned error is not `*executor.CommandNotFoundError`, but does not fail. This makes the test pass even if the executor stops returning the expected error type.
## Issue Context
`executor.Execute` explicitly returns `*executor.CommandNotFoundError` when a command is not found.
## Fix Focus Areas
- integration-tests/error_test.go[43-46]
- internal/executor/executor.go[103-110]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

ⓘ The new review experience is currently in Beta. Learn more

[Copilot]

Pull request overview

This PR reorganizes the integration-tests e2e suite by splitting Spring tests into separate Maven/Gradle files and introducing go-zero integration coverage.

Changes:

• Split Spring Boot e2e tests into Maven- and Gradle-specific test files.
• Add go-zero e2e tests covering detection, generation, and “no goctl” behavior.
• Extract the mock LLM provider into a shared test helper file.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
integration-tests/spring_maven_test.go	Removes Gradle + error-handling + mock provider code from Maven Spring test file after split.
integration-tests/spring_gradle_test.go	New Gradle-specific Spring Boot generation/validation e2e test.
integration-tests/mock_provider_test.go	New shared mock provider used by enrich flow tests.
integration-tests/gozero_test.go	New go-zero e2e tests (detect/generate/no-goctl).
integration-tests/error_test.go	New dedicated error-handling e2e test for missing command execution.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 10 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 11 changed files in this pull request and generated 5 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 11 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

This e2e test writes openapi.yaml into the checked-in demo project directory (hence the added .gitignore entries). To avoid polluting the working tree and to make runs more hermetic, set GenerateOptions.OutputDir (and optionally OutputFile) to a t.TempDir() location.

Suggested change

	result, err := gen.Generate(ctx, projectPath, info, &extractor.GenerateOptions{
	Format: "yaml",
	outputDir := t.TempDir()
	result, err := gen.Generate(ctx, projectPath, info, &extractor.GenerateOptions{
	Format: "yaml",
	OutputDir: outputDir,
	OutputFile: "openapi.yaml",

[Copilot]

Installing goctl@latest makes CI non-reproducible (a new goctl release can break the pipeline without code changes). Consider pinning to a specific version (ideally matching the go-zero version used in integration-tests/gozero-demo/go.mod) or centralizing the version in a workflow/env var.

[Copilot]

The docs recommend go install .../goctl@latest, which is convenient but can lead to non-reproducible e2e runs when goctl behavior changes. Consider documenting a pinned goctl version (matching the demo project's go-zero dependency) or at least noting that @latest may cause test drift over time.

Suggested change

	- **goctl** - Required for go-zero projects. Install with:
	```bash
	go install github.com/zeromicro/go-zero/tools/goctl@latest
	```
	- **goctl** - Required for go-zero projects. Install with a version pinned to the go-zero dependency used in the `gozero-demo` project, for example:
	```bash
	go install github.com/zeromicro/go-zero/tools/goctl@vX.Y.Z

Note: Using @latest can change goctl behavior over time and may cause end-to-end tests to drift.

[Copilot]

The require entry on go.yaml.in/yaml/v2 introduces a likely typosquatted and potentially malicious replacement for the legitimate gopkg.in/yaml.v2 module, creating a supply-chain risk. Including this module in go.mod allows it to be fetched and built in developer or CI environments, where it could run arbitrary code with access to secrets. Remove this requirement and, if YAML parsing is needed, depend on the official gopkg.in/yaml.v2 module instead.