test: add language starter module back to sonar analysis

[emmileaf]

This PR update sonar exclusion on spring-cloud-previews so that analysis runs on google-cloud-language-spring-starter, which contain the handwritten unit tests. This allows for some indication of missing coverage should there be broader configuration code changes introduced by the generator.

• Also updates the tests so that existing code coverage is sufficient (previously missing for some method-level retry property setters)

[emmileaf]

Note: the final sonarcloud comment will show "no coverage info" on this PR because it does not make any changes to the autoconfiguration code. With the mock changes in commit b7acf97, this analysis looks like below, catching changes to the google-cloud-language-spring-starter module and indicating missing coverage on new lines:

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.0% Duplication

[meltsufin]

LGTM.
PS: I didn't realize we were mixing auto-generated code with handwritten, although it's just tests. I'm curious @blakeli0's opinion on this. Is this a testing strategy we want to employ?

[zhumin8]

LGTM.
About test strategy, we created manual written unit test for one sample generated module and it is "mixed-in" as copied from template folder to generated code to run test with any updates to the generated module. It's the simplest setup to have coverage on the generated code.
Alternative could be to copy generated "language-starter" module after generated to a separate un-published module where these tests locates and do testing there. What do you all think? @emmileaf @meltsufin @blakeli0 Is it worth the change so we can keep generated code modules clean from manual code?

[meltsufin]

LGTM. About test strategy, we created manual written unit test for one sample generated module and it is "mixed-in" as copied from template folder to generated code to run test with any updates to the generated module. It's the simplest setup to have coverage on the generated code. Alternative could be to copy generated "language-starter" module after generated to a separate un-published module where these tests locates and do testing there. What do you all think? @emmileaf @meltsufin @blakeli0 Is it worth the change so we can keep generated code modules clean from manual code?

I think that the purpose of the tests is to test the Spring starter generator. So, I wonder if you considered generating a starter for Showcase (or another API) and writing manual tests against it, all inside the spring-cloud-generator module?

[emmileaf]

Thanks for the reviews @meltsufin @zhumin8 !

I think that the purpose of the tests is to test the Spring starter generator. So, I wonder if you considered generating a starter for Showcase (or another API) and writing manual tests against it, all inside the spring-cloud-generator module?

1355 has some context from when these handwritten unit tests were first added - I recall the initial reasoning for not using showcase being 1) it required additional setup, and 2) showcase module provides power of coverage for client library functionalities, whereas the generated code are just an integration layer on top of these.

The purpose of these handwritten unit tests is to have some test coverage for generated code, alongside the golden tests we have for the generator itself.

Alternative could be to copy generated "language-starter" module after generated to a separate un-published module where these tests locates and do testing there.

Regarding where these tests should live, whether alongside the generated code or in a separate module: copying the generated module and running this test elsewhere is definitely an option, and I also wonder if there is a way to relocate the test code but still run it on the generated module. With the plan to add a manual integration test layer (auth, several services working together), having a separate module for handwritten tests does makes sense to me.

I’ll go ahead and merge this PR for now, but will follow-up with exploring/revisiting some of these options. (Happy to continue the discussion in this thread as well)