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

Address SonarCloud issues #3666

Merged
merged 4 commits into from Jan 24, 2021
Merged

Conversation

rhowe
Copy link
Contributor

@rhowe rhowe commented Jan 24, 2021

Problem:

Sonar is grumbling about a few things. Some aren't so valid and others I'm not too sure about, but the ones addressed by this PR do seem to be genuine:

These two:
https://sonarcloud.io/project/issues?id=dropwizard_dropwizard&issues=AXUXdIJdpBosHuY9-PuM&open=AXUXdIJdpBosHuY9-PuM
https://sonarcloud.io/project/issues?id=dropwizard_dropwizard&issues=AXUXdIIWpBosHuY9-Ptj&open=AXUXdIIWpBosHuY9-Ptj
relate to tests in dropwizard-example asserting that a long is not null, which isn't really proving anything.

These two:
https://sonarcloud.io/project/issues?id=dropwizard_dropwizard&issues=AXUXdIWFpBosHuY9-Pyx&open=AXUXdIWFpBosHuY9-Pyx
https://sonarcloud.io/project/issues?id=dropwizard_dropwizard&issues=AXUXdIWFpBosHuY9-Py7&open=AXUXdIWFpBosHuY9-Py7

relate to the @Nested annotation being used in dropwizard-jetty's ZipExceptionHandlingInputStreamTest. This actually exposes the fact that these tests aren't being run because by default, surefire doesn't run tests in static inner classes!

Solution:

Remove the assertions which can't fail in dropwizard-example.

Split ZipExceptionHandlingInputStreamTest into two test classes. Since one of the inner classes was a parameterised test, it needed a static field and so the alternative was to reconfigure surefire. That seemed like a bit of a heavy-handed option so I just split the test up instead. I changed the @Test annotations to @ParameterizedTest as suggested by IntelliJ - not 100% sure that was the right thing to do, but it knows Java better than I.

Whilst we're in there, tidy up the assertions to use assertThatExceptionOfType instead of open-coding a try-catch.

Result:

Fewer Sonar errors, more tests being run, test code is a bit simpler.

SonarCloud picked this one up - Person#getId returns a long, so there isn't
really a decent test we can do here.
Remove spurious import of StandardCharsets and extraneous exception declarations.
…it gets run

The default surefire configuration doesn't execute tests in static inner
classes. We can't easily make the inner classes non-static because of the
parameterized tests, so just split the test class into two classes instead.
We can use AssertJ's built-in Exception handling assertions instead of
open-coding a try-catch.
@rhowe rhowe changed the title Appease sonarcloud Appease Sonar Jan 24, 2021
Copy link
Member

@joschi joschi left a comment

Choose a reason for hiding this comment

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

Thanks!

@joschi joschi added this to the 2.0.19 milestone Jan 24, 2021
@joschi joschi changed the title Appease Sonar Address SonarCloud issues Jan 24, 2021
@joschi joschi merged commit 7d6d94a into dropwizard:master Jan 24, 2021
@rhowe rhowe deleted the appease-sonarcloud branch January 25, 2021 09:10
joschi pushed a commit that referenced this pull request Jan 26, 2021
- Remove the assertions which can't fail in dropwizard-example.
- Split `ZipExceptionHandlingInputStreamTest` into two test classes. Since one of the inner classes was a parameterised test, it needed a static field and so the alternative was to reconfigure surefire. That seemed like a bit of a heavy-handed option so I just split the test up instead. I changed the `@Test` annotations to `@ParameterizedTest` as suggested by IntelliJ.

(cherry picked from commit 7d6d94a)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants