-
Notifications
You must be signed in to change notification settings - Fork 1.3k
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
Help fix broken / ignored unit tests or other analytics! #3859
Comments
Wanted to leave this link here as well: https://github.com/jenkinsci/warnings-ng-plugin/blob/master/doc/Documentation.md It goes a bit beyond the origin of this issue, but beyond hooking analytics back up in the new Jenkins at all there are so many options floating around for how we could do more. I also tried to enable the Sonarsource web scanner but while it worked fine for one project dynamically making it figure out multiple from one set of config / add more as needed without manual action might take a bit more work |
How's the code coverage? I've worked with JUnit and Mockito before and would be happy to work with unit tests. |
Hi @lizzyd710! ... well, we have some! 😁 But 700+ tests barely make a dent in the engine project here when it comes to percentage coverage, then there are oodles of modules and other side projects. We're always low on tests - any assistance writing more would be really appreciated! |
In
In |
Sure, at this point I'm less worried about the tests stalling in our Jenkins server, since that'll get tested as part of a PR now. Previously when I ignored things and wrote this issue we were still trying to get our build server up and running properly :-) |
Is this issue still open? |
@pree-T Generally yes. It does need a decent bit of investigation first, though. But sure, go ahead, give it a try and ideally first drop your findings about broken or ignored tests in here before starting to try to fix them 😉 |
when building with java-11 it ends with:
i'll give to fix these ones a try. |
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see MovingBlocks#3859
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule pmd warnings not yet addressed, there are some log guard related, which are false positive. see MovingBlocks#3859 typehandlerlibrary qa, checkstyle squash to qa
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule pmd warnings not yet addressed, there are some log guard related, which are false positive. see MovingBlocks#3859 typehandlerlibrary qa, checkstyle squash to qa
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule pmd warnings not yet addressed, there are some log guard related, which are false positive. see MovingBlocks#3859 typehandlerlibrary qa, checkstyle squash to qa
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule pmd warnings not yet addressed, there are some log guard related, which are false positive. see MovingBlocks#3859 typehandlerlibrary qa, checkstyle squash to qa
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule pmd warnings not yet addressed, there are some log guard related, which are false positive. see MovingBlocks#3859 typehandlerlibrary qa, checkstyle squash to qa
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule pmd warnings not yet addressed, there are some log guard related, which are false positive. see MovingBlocks#3859 typehandlerlibrary qa, checkstyle squash to qa
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule especially in tests just quite the warnings, in most cases the code is deliberate as it is. see MovingBlocks#3859
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule especially in tests just quite the warnings, in most cases the code is deliberate as it is. see MovingBlocks#3859 and see bugs: * pmd/pmd#4731 * spotbugs/spotbugs-gradle-plugin#1018 * spotbugs/spotbugs#2667
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule especially in tests just quite the warnings, in most cases the code is deliberate as it is. see MovingBlocks#3859 and see bugs: * pmd/pmd#4731 * spotbugs/spotbugs-gradle-plugin#1018 * spotbugs/spotbugs#2667
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule especially in tests just quite the warnings, in most cases the code is deliberate as it is. see MovingBlocks#3859 and see bugs: * pmd/pmd#4731 * spotbugs/spotbugs-gradle-plugin#1018 * spotbugs/spotbugs#2667
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule especially in tests just quite the warnings, in most cases the code is deliberate as it is. see MovingBlocks#3859 and see bugs: * pmd/pmd#4731 * spotbugs/spotbugs-gradle-plugin#1018 * spotbugs/spotbugs#2667
* make final fields static * remove unnecessary local before return * remove instanceof checks in catch clause * avoid throwing java.lang.Exception * remove null checks covered by instanceof check * remove toString on String objects * remove overrides that only call their super * remove unused private methods * remove unnecessary if statement nesting * remove unused local variables * use try-with-resources to close resources after use * use equals() to compare object references * fix broken javadoc references * fix disallowed self-closing and empty javadoc elements * fix bad use of symbols in javadoc * fix disallowed list item tag in javadoc without surrounding list * fix erroneous javadoc tags * fix emphasize tags in javadoc * remove illegal throws * remove unused imports Related: Terasology/CoreRendering#75 Terasology/Furnishings#17 Terasology/Health#105 Terasology/Inventory#51 Terasology/Behaviors#114 Terasology/CoreWorlds#45 Terasology/FlexiblePathfinding#32 Adds to #3859
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule especially in tests just quite the warnings, in most cases the code is deliberate as it is. see MovingBlocks#3859 and see bugs: * pmd/pmd#4731 * spotbugs/spotbugs-gradle-plugin#1018 * spotbugs/spotbugs#2667
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule especially in tests just quite the warnings, in most cases the code is deliberate as it is. see MovingBlocks#3859 and see bugs: * pmd/pmd#4731 * spotbugs/spotbugs-gradle-plugin#1018 * spotbugs/spotbugs#2667
as a workaround, add dependency for spotbugs annotations, and create a [ticket there so the spotbugs gradle plugin would include the dependency] (spotbugs/spotbugs-gradle-plugin#1018). see here a motivation for inner type last rule. if we leave the rule we should respect it, otherwise disable the rule. https://stackoverflow.com/questions/25158939/what-motivation-is-behind-checkstyle-inner-type-last-rule especially in tests just quite the warnings, in most cases the code is deliberate as it is. see MovingBlocks#3859 and see bugs: * pmd/pmd#4731 * spotbugs/spotbugs-gradle-plugin#1018 * spotbugs/spotbugs#2667
After merging #3856 one unit test class,
TypeRegistryTest
, intermittently stalled during local testing. It may be fine on some OSes or in Jenkins, but oddly it stalled even with the@Ignored
annotation added to the tests. It would be good if a few different people to re-enable those tests and run them locally several times (one at a time, all three at once, etc) and make sure they don't stall - if not then we can re-enable and I'll just blame my workspace.Additionally at present we skip 7 tests in
EntityAwareWorldProviderTest
and another 7 inParallelTest
for reasons of the past I don't remember off the top of my head, but the files and Git / GitHub history may help shed some background info on that topic.Finally there are two tests in the ModuleTestingEnvironment that are getting stuck in infinite loops for me testing locally in
LocalChunkProvider.checkForUnload()
- not sure that'd relate to these changes. ClientConnectionTest and ExampleTestBeyond unit tests there are plenty of other code analytics that result in issues, although the stats are still only published in our new Jenkins which isn't exposed publicly yet, although regular contributors can request access any time for some insight. In the meantime you can run
gradlew check
locally and find an abundance of warnings :-)In Jenkins specifically unit tests tend to fail if they involve a game environment, #3415 has the details and it would be a lovely thing to fix as well.
Marking Good First Issue as these topics are all mildly unrelated to anything else and decent detective hunts for curious contributors, even if they aren't necessarily going to be easy!
Edit: there is also a weird issue where SpotBugs works for some modules but not others, resulting in no
build/reports/spotbugs
directory. I saw an error related to it at one point, but forgot where. It showed both locally and in Jenkins so it shouldn't be hard to replicate if looking across a few modules. Pretty sure Pathfinding had the failure. Could rungradlew spotbugsMain
to selectively just run SpotBugs in a workspace then go looking for which modules made that build dir or not.The text was updated successfully, but these errors were encountered: