-
Notifications
You must be signed in to change notification settings - Fork 0
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
Add unit tests for Java, split test cases per language #42
Add unit tests for Java, split test cases per language #42
Conversation
resources/java/WhileAndForLoop.java
Outdated
System.out.println("Iteration " + (counter + 1)); | ||
counter++; | ||
} | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- do while,
- for(var item : items),
- what about Iterable.foreach(() => {}). How is this case handled e.g. in Sonar?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
According to https://docs.sonarsource.com/sonarqube/latest/user-guide/metric-definitions/, SonarQube does increase the complexity by one for "if, for, while, case, &&, ||, ?, ->". That means that in your example, it would actually increase the complexity by one, but not because of the "foreach"-call itself, but because of the lambda function with the arrow operator. Calling foreach with some non-lambda function should not do anything accordingly.
I guess that whole discussion should be part of #41, however
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This question is not blocking the extension of more cases for control structures in this code file.
PTAL, in general LGTM. |
I guess this is still in progress, so I moved it into the right state :-) |
6f33593
to
10363b9
Compare
We have encountered an issue where some tests "just fail" because of tree.rootNode being undefined when running all tests (both test.ts files and compiled .test.js files) e.g. via "npm test". This seems to be triggered by the higher number of test files or test cases in this PR, but also happened seldomly before. As it turns out, this is probably caused by a race condition in the tree-sitter library. We probably cannot do anything here to handle this issue on our side... |
dede3c2
to
006fb96
Compare
…r.calculateMetrics()
67ba45b
to
36dacf3
Compare
It turned out that this issue is triggered especially if the number of test files is higher than the number of worker processes used by jest. |
151bedd
to
4316cef
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All remarks are solved.
Added unit tests for basic file metrics for java source code. Also introduces a new function to reduce code duplication inside the test case. Splits the test cases of GenericParser.test.ts into multiple test files, to have one test file for each programming language.
MCC is not yet tested due to the unclear definition of that metric (see #41).
Main author @mylinhdao
Closes #40