Skip to content

Conversation

musicpulpite
Copy link
Collaborator

@musicpulpite musicpulpite commented Sep 10, 2025

Description

Linear ticket: FER-6290

Following the basic structure laid out for Java here create a WireTestGenerator that creates basic wire tests using go-wiremock. This feature will be enabled using the customConfig.enableWireTests flag.

TO-DO Items

See pending items in the [SDKs] Go Wire tests Linear project. Namely:

  1. Fix existing dynamic snippets
  2. Refactor to follow pattern established for Java wire tests
  3. Add request body validation and accurate mock response bodies
  4. Refactor to use homebrewed mock server
  5. Potentially refactor to co-locate tests with packages

Changes Made

  • Add methods to EndpointSnippetGenerator
  • Create WireTestGenerator class to effectively wrap endpoint snippet generation
  • Fix golang AsIs file functionality

Testing

  • I've generated auth0's go-sdk using FROND and played around with it

return s;
}
return split[0].replace(INVALID_GO_IDENTIFIER_TOKEN, "");
return split.map((part) => part.replace(INVALID_GO_IDENTIFIER_TOKEN, "")).join("");
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't have go-wiremock alias as go

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess we do need to be careful that this is not breaking behavior for package consumers.

But I don't think it is since it's just changing the alias we use in generated files, it isn't actual changing package names that the consumer might try to import and use without aliasing. But double check me on that!

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yea as this is a writer change can this impact any other code generation parts?

@@ -0,0 +1,57 @@
package wiremock
Copy link
Collaborator Author

@musicpulpite musicpulpite Sep 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This file is useful to run once for the entire test suite since initializing the wiremock test container does incur overhead. It can then be used in all individual test cases in the package

options?: Options
): Promise<FernIr.dynamic.EndpointSnippetResponse> {
return super.generate(request);
return super.generate(request, options);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since options is untyped and optional its the best way for me to pass in new options to the dynamic snippets endpoint generator to create "unit test case" snippets without breaking the abstract interface for all other users of DynamicSnippetsGenerator

});
}

public static chainMethods(
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I could be convinced that a utility like this should be added onto the go.FuncInvocation type itself... open to other ideas here but the usefulness should be clear

@musicpulpite musicpulpite marked this pull request as ready for review September 11, 2025 16:35

await context.snippetGenerator.populateSnippetsCache();

if (context.config.writeUnitTests) {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it valid here to use the base config option writeUnitTest (currently unused) or should I create a new more specific enableWireTests etc flag? Will we ever want this specificity in the future?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The realization is that writeUnitTests is enabled by default across all generators (but check me on that) so in order to make this feature "opt-in" to begin with I will need to create a new customConfig flag for the go generator probably called enableWireTests as well!

return response.snippet;
}

private parseEndpointTestCaseSnippet(fileString: string): [string, Map<string, string>] {
Copy link
Collaborator Author

@musicpulpite musicpulpite Sep 16, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The endpoint snippet (with config.outputWiremockTests) writes a complete test file for the single endpoint test method. I think its more meaningful to keep that behavior and then parse out the function body and imports in the consuming code. We can then collate the test methods by service

RUN git config --global user.name "fern" && git config --global user.email "[email protected]"

COPY generators/go-v2/sdk/dist/cli.cjs /dist/cli.cjs
COPY generators/go-v2/sdk/dist/ /dist/
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is necessary for getting the AsIs file behavior to work for the v2 go generator. The AsIs files get copied into /dist/ along with the javascript bundle during pnpm dist:cli.

@@ -0,0 +1,72 @@
package wiremock
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here's the generated tests... which do pass!

@musicpulpite
Copy link
Collaborator Author

I'm still looking into why this new seed test fails and why this new dependency adds a "toolchain" line:

[go-sdk:imdb:with-wiremock-tests]:  Running script CGO_ENABLED=0 go test ./... on imdb:with-wiremock-tests
go: errors parsing go.mod:
/imdb_with-wiremock-tests/generated/go.mod:5: unknown directive: toolchain

@musicpulpite musicpulpite merged commit e5a3d82 into main Sep 16, 2025
39 checks passed
@musicpulpite musicpulpite deleted the FER-6290/go-wire-tests-2 branch September 16, 2025 19:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants