Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

test(codegen): add unit tests for one generated starter module #1355

Merged
merged 12 commits into from
Jan 3, 2023

Conversation

emmileaf
Copy link
Contributor

@emmileaf emmileaf commented Nov 21, 2022

This PR:

  • Adds LanguageAutoConfigurationTests.java (and resource files), which contains handwritten unit tests (adapted from the POC) for the corresponding generated google-cloud-language-spring-starter module.

Notes for review:

  • Would appreciate feedback on any missing feature coverage!
  • I have been testing this branch against a local copy of generated google-cloud-language-spring-starter module, which I could also temporarily commit if it makes reviewing easier?

Current test setup depends on the following changes in generator code:

@emmileaf emmileaf marked this pull request as ready for review December 19, 2022 15:11
Copy link
Member

@meltsufin meltsufin left a comment

Choose a reason for hiding this comment

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

I assume you intend these tests to be autogenerated. If that being the case, I'm curious what @blakeli0 and @burkedavison think about that because we've recently had discussions about pros and cons of auto-generating unit tests.

this.contextRunner.run(
ctx -> {
LanguageServiceClient client = ctx.getBean(LanguageServiceClient.class);
assertThat(client.getSettings().getCredentialsProvider()).isNotNull();
Copy link
Member

Choose a reason for hiding this comment

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

Wouldn't this be true even when properties were provided, like in the test above?

Copy link
Contributor Author

@emmileaf emmileaf Dec 20, 2022

Choose a reason for hiding this comment

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

Right - the intention I had for this test is to ensure that when no service-specific properties are provided, the configuration picks up the CredentialsProvider bean from spring-cloud-gcp-autoconfigure (as introduced in #1123). I’ve updated the test to better reflect this scenario.

}

@Test
void testShouldUseDefaultGrpcTransport() {
Copy link
Member

Choose a reason for hiding this comment

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

Is there a test for the opposite, or we only allow grpc at this point?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

We are only generating for grpc client libraries in the initial list. But on a second thought, this test could have been set up in a better way. I've update it to check instead that the client library default TransportChannelProvider is used when no overrides are present.

@emmileaf
Copy link
Contributor Author

emmileaf commented Dec 19, 2022

I assume you intend these tests to be autogenerated. If that being the case, I'm curious what @blakeli0 and @burkedavison think about that because we've recently had discussions about pros and cons of auto-generating unit tests.

@meltsufin Thank you for the review! I'll follow-up on the in-line comments individually but just wanted to quickly respond to this note - these are intended to be manually-written tests (for one example module) as an initial testing strategy we've decided for spring codegen, given the discussion on moving away from autogenerated unit tests as you've mentioned.

(We’ve also considered the showcase module for unit testing, but decided to go with an example module for now given we are testing an integration layer and not for any client library functionalities that showcase provides power of coverage for.)

@burkedavison
Copy link
Member

... these are intended to be manually-written tests (for one example module) as an initial testing strategy we've decided for spring codegen, given the discussion on moving away from autogenerated unit tests as you've mentioned.

(We’ve also considered the showcase module for unit testing, but decided to go with an example module for now given we are testing an integration layer and not for any client library functionalities that showcase provides power of coverage for.)

I agree this is consistent with our general strategy. Handwritten unit tests should continue to be implemented whenever appropriate. Autogenerated unit tests should not.

zhumin8 added a commit to googleapis/sdk-platform-java that referenced this pull request Dec 22, 2022
Copy link
Contributor

@zhumin8 zhumin8 left a comment

Choose a reason for hiding this comment

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

LGTM.

}

@Test
void testShouldUseDefaultTransportChannelProvider() {
Copy link
Contributor

Choose a reason for hiding this comment

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

For the sake of coverage, you might also want to add a testCustomTransportChannelProviderSetToRest?
when property "com.google.cloud.language.v1.language-service.useRest=true" present,
we should expect the transportChannelProvider set to

LanguageServiceSettings.defaultHttpJsonTransportProviderBuilder().build();

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thank you for this suggestion and added! I think it also addresses what I missed earlier in #1355 (comment).

@sonarcloud
Copy link

sonarcloud bot commented Jan 3, 2023

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 0 Code Smells

No Coverage information No Coverage information
No Duplication information No Duplication information

@emmileaf emmileaf changed the title test(codegen): add unit tests for sample autogenerated module test(codegen): add unit tests for one generated starter module Jan 3, 2023
@emmileaf emmileaf merged commit 23f9aa4 into main Jan 3, 2023
@emmileaf emmileaf deleted the codegen-test-language branch January 3, 2023 16:14
zhumin8 added a commit that referenced this pull request Jan 11, 2023
…ifier name. (#1418)

This is a followup on #1355, the additional test verifies in case of multiple bean of type `TransportChannelProvider` the one with correct qualifier name is used. 
related fix in generator: googleapis/sdk-platform-java#1207
emmileaf added a commit that referenced this pull request Jan 11, 2023
…dule unit tests (#1443)

This PR patches unit tests added in #1355 to all have mock top-level credentials configured.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants