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

JS-155 SonarJS exposes entry point to the parser for testing #4734

Merged
merged 9 commits into from
Jun 14, 2024

Conversation

quentin-jaquier-sonarsource
Copy link
Contributor

No description provided.

* This class will contain only information required by {@link BridgeServerImpl}.
* This will reduce the dependency on external API, and ease the testing.
*/
public record BridgeServerConfig(Configuration config, String workDirAbsolutePath, SonarProduct product) {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

It is a first step toward removing the dependency over sonar.api in the Bridge. I failed to remove everything, as we rely deeply on the Configuration object. I tried to wrap the object, store only the result that we need, but both solution result in a lot of non-trivial changes.

It is a bit annoying, as it means you will need to have the classes from sonar.api when using the standalone... But I'm afraid we will have to deal with it for now.

@quentin-jaquier-sonarsource
Copy link
Contributor Author

I still miss a bit of coverage. I'm really surprised to see the lines in StandaloneTemporaryFolder, as I have an explicit test for it. It looks like a bug from the code coverage tool.
The rest are exceptional cases, that are cumbersome to test in a meaningful way. I would be in favor of not bothering covering those. Let me know what you think.

@Test
void should_throw_exception_when_fail_to_parse_code() {
assertThatThrownBy(() -> parser.parse("..."))
.isInstanceOf(IllegalStateException.class)
Copy link
Contributor

Choose a reason for hiding this comment

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

maybe throw ParseException instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

After thinking about it, this exception takes an offset, I'm not sure it makes sense in our context. It is probably meant to be used when parsing Java Objects.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

As discussed, let's use IllegalArgumentException instead.

Copy link
Contributor

@ilia-kebets-sonarsource ilia-kebets-sonarsource left a comment

Choose a reason for hiding this comment

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

one small change proposal, otherwise LGTM

Copy link

Quality Gate failed Quality Gate failed

Failed conditions
85.4% Coverage on New Code (required ≥ 90%)

See analysis details on SonarQube

@ilia-kebets-sonarsource ilia-kebets-sonarsource merged commit cabb075 into master Jun 14, 2024
13 of 15 checks passed
@ilia-kebets-sonarsource ilia-kebets-sonarsource deleted the qj/JS-155 branch June 14, 2024 12:35
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.

2 participants