feat: add integration tests for Java, NestJS, and React generators#221
feat: add integration tests for Java, NestJS, and React generators#221vikasrao23 wants to merge 1 commit intoopen-feature:mainfrom
Conversation
Implements integration test coverage for Java, NestJS, and React generators following the standardized Dagger-based testing pattern. Changes: **Java (open-feature#115):** - test/integration/cmd/java/run.go - Dagger test runner - test/java-integration/pom.xml - Maven configuration - test/java-integration/src/main/java/dev/openfeature/Main.java - Test program - Validates all flag types with OpenFeature Java SDK **NestJS (open-feature#116):** - test/integration/cmd/nestjs/run.go - Dagger test runner - test/nestjs-integration/package.json - npm configuration - test/nestjs-integration/tsconfig.json - TypeScript config - test/nestjs-integration/src/main.ts - NestJS test application - Tests generated code with @openfeature/nestjs-sdk **React (open-feature#118):** - test/integration/cmd/react/run.go - Dagger test runner - test/react-integration/package.json - npm configuration - test/react-integration/tsconfig.json - TypeScript config - test/react-integration/src/test.ts - Hook structure validation - Validates generated hooks compile and have correct API **Shared:** - test/integration/cmd/run.go - Added all three tests to main runner - Makefile - Added test-integration-java, test-integration-nestjs, test-integration-react targets All tests: 1. Build the CLI from source 2. Generate language-specific code 3. Compile and validate generated code 4. Run as part of CI suite via test-integration Acceptance criteria met: ✅ Java, NestJS, React generators covered by integration tests ✅ Generated code compiles and passes execution/validation ✅ Tests integrated into CI suite ✅ Follow documented integration testing structure Closes open-feature#115 Closes open-feature#116 Closes open-feature#118 Signed-off-by: vikasrao23 <vikasrao23@users.noreply.github.com>
Summary of ChangesHello @vikasrao23, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly enhances the reliability of the OpenFeature CLI by adding robust integration tests for its Java, NestJS, and React code generators. By leveraging Dagger, these tests provide a consistent and isolated environment to validate the generated code's functionality, ensuring it compiles correctly and accurately evaluates feature flags across various types and methods. This improves developer confidence and streamlines the development workflow for future generator enhancements. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request adds comprehensive integration tests for the Java, NestJS, and React code generators, following the existing Dagger-based testing pattern. The changes are well-structured and the tests cover the core functionality of the generated code. I have a couple of suggestions to improve maintainability and performance by refactoring duplicated code and enabling parallel test execution. Overall, this is a great addition for ensuring the quality of the code generators.
| cli := client.Container(). | ||
| From("golang:1.24-alpine"). | ||
| WithExec([]string{"apk", "add", "--no-cache", "git"}). | ||
| WithDirectory("/src", source). | ||
| WithWorkdir("/src"). | ||
| WithExec([]string{"go", "mod", "tidy"}). | ||
| WithExec([]string{"go", "mod", "download"}). | ||
| WithExec([]string{"go", "build", "-o", "cli", "./cmd/openfeature"}) |
There was a problem hiding this comment.
There's a significant amount of duplicated code for building the CLI across the new integration test runners (java/run.go, nestjs/run.go, react/run.go). This logic is identical in each file.
To improve maintainability and reduce redundancy, consider refactoring this into a shared helper function within the integration package.
For example, you could create a BuildCLI function in test/integration/integration.go:
// in test/integration/integration.go
func BuildCLI(client *dagger.Client, source *dagger.Directory) *dagger.Container {
return client.Container().
From("golang:1.24-alpine").
WithExec([]string{"apk", "add", "--no-cache", "git"}).
WithDirectory("/src", source).
WithWorkdir("/src").
WithExec([]string{"go", "mod", "tidy"}).
WithExec([]string{"go", "mod", "download"}).
WithExec([]string{"go", "build", "-o", "cli", "./cmd/openfeature"})
}Then, you could call it from each test runner like this:
cli := integration.BuildCLI(client, source)| // Run the Java integration test | ||
| javaCmd := exec.Command("go", "run", "github.com/open-feature/cli/test/integration/cmd/java") | ||
| javaCmd.Stdout = os.Stdout | ||
| javaCmd.Stderr = os.Stderr | ||
| if err := javaCmd.Run(); err != nil { | ||
| fmt.Fprintf(os.Stderr, "Error running Java integration test: %v\n", err) | ||
| os.Exit(1) | ||
| } | ||
|
|
||
| // Run the NestJS integration test | ||
| nestjsCmd := exec.Command("go", "run", "github.com/open-feature/cli/test/integration/cmd/nestjs") | ||
| nestjsCmd.Stdout = os.Stdout | ||
| nestjsCmd.Stderr = os.Stderr | ||
| if err := nestjsCmd.Run(); err != nil { | ||
| fmt.Fprintf(os.Stderr, "Error running NestJS integration test: %v\n", err) | ||
| os.Exit(1) | ||
| } | ||
|
|
||
| // Run the React integration test | ||
| reactCmd := exec.Command("go", "run", "github.com/open-feature/cli/test/integration/cmd/react") | ||
| reactCmd.Stdout = os.Stdout | ||
| reactCmd.Stderr = os.Stderr | ||
| if err := reactCmd.Run(); err != nil { | ||
| fmt.Fprintf(os.Stderr, "Error running React integration test: %v\n", err) | ||
| os.Exit(1) | ||
| } |
There was a problem hiding this comment.
The main integration test runner executes each test sequentially. This can be inefficient, especially as more tests are added. The PR description also mentions that tests can run in parallel. To improve performance and align with that benefit, consider refactoring this to run the tests concurrently using goroutines and a sync.WaitGroup. This would also reduce code duplication.
Here's a conceptual example of how you could structure it:
func main() {
fmt.Println("=== Running all integration tests ===")
tests := map[string]string{
"C#": "github.com/open-feature/cli/test/integration/cmd/csharp",
"Go": "github.com/open-feature/cli/test/integration/cmd/go",
"NodeJS": "github.com/open-feature/cli/test/integration/cmd/nodejs",
"Angular": "github.com/open-feature/cli/test/integration/cmd/angular",
"Java": "github.com/open-feature/cli/test/integration/cmd/java",
"NestJS": "github.com/open-feature/cli/test/integration/cmd/nestjs",
"React": "github.com/open-feature/cli/test/integration/cmd/react",
}
var wg sync.WaitGroup
errChan := make(chan error, len(tests))
for name, path := range tests {
wg.Add(1)
go func(name, path string) {
defer wg.Done()
cmd := exec.Command("go", "run", path)
cmd.Stdout = os.Stdout
cmd.Stderr = os.Stderr
if err := cmd.Run(); err != nil {
errChan <- fmt.Errorf("error running %s integration test: %w", name, err)
}
}(name, path)
}
wg.Wait()
close(errChan)
hasErrors := false
for err := range errChan {
fmt.Fprintln(os.Stderr, err)
hasErrors = true
}
if hasErrors {
os.Exit(1)
}
fmt.Println("=== All integration tests passed successfully ===")
}
|
Closing this combined PR in favor of three separate, focused PRs:
This makes reviewing and merging easier! |
1 participant
Summary
Fixes #115, #116, #118
Implements comprehensive integration test coverage for three code generators (Java, NestJS, React) following the standardized Dagger-based testing pattern.
Changes by Generator
🟠 Java (#115)
New Files:
test/integration/cmd/java/run.go- Dagger test runnertest/java-integration/pom.xml- Maven project configurationtest/java-integration/src/main/java/dev/openfeature/Main.java- Test programTest Coverage:
.value()and.valueWithDetails()methods.getKey()method🟢 NestJS (#116)
New Files:
test/integration/cmd/nestjs/run.go- Dagger test runnertest/nestjs-integration/package.json- npm configurationtest/nestjs-integration/tsconfig.json- TypeScript configtest/nestjs-integration/src/main.ts- NestJS application testTest Coverage:
.value()and.valueWithDetails()methods.getKey()method⚛️ React (#118)
New Files:
test/integration/cmd/react/run.go- Dagger test runnertest/react-integration/package.json- npm configurationtest/react-integration/tsconfig.json- TypeScript configtest/react-integration/src/test.ts- Hook structure validationTest Coverage:
.useFlag(),.useFlagWithDetails(),.getKey())🔧 Shared Updates
test/integration/cmd/run.go- Added Java, NestJS, and React to main test runnerMakefile- Added individual targets:make test-integration-javamake test-integration-nestjsmake test-integration-reactHow It Works
Each test follows the same Dagger-based pattern:
cli generate <language>with sample manifestBenefits
Running the Tests
Run individual tests:
Run all integration tests:
Example Output
Java:
NestJS:
React:
Acceptance Criteria
Java (#115):
NestJS (#116):
React (#118):
Additional Notes
Signed-off-by: vikasrao23 vikasrao23@users.noreply.github.com