3 ms·
We frequently have the issue of, upon refactoring code in such a way that involves moving it and its tests to a new file, Sonar will take away our previous "cre
by nsxwolf 2y ago
We frequently have the issue of, upon refactoring code in such a way that involves moving it and its tests to a new file, Sonar will take away our previous "credit" for code coverage percentage, dropping our project below the threshold and failing.
The only workaround I've found is to create a new function, fill it full of many useless no-op lines, and write a test for that function, just to bump the percentages back up. This is often harder than it sounds, because the linter will block many types of useless no-op code. We then remove the code as part of another ticket.
- lesuorac 2y agoHeh, at one place I wrote some java code that would use reflections to test the getter/setters in a POJO so that it wouldn't end up with 0% code coverage.
- cuteboy19 2y agogetter setters w/o buisness logic seem like an antipattern though. let spring or some other annotation handle those
- lesuorac 2y agoEh, whats the difference between spring auto-generating them at build time via an annotation or an IDE auto-generating them at write time?
- cuteboy19 2y agocoverage is not affected
- hsbbxbyb 2y agoIDE auto generation is frozen in time. You have a bunch of useless boilerplate you still need to look at to make sure nobody did something unexpected in them When annotation generated or reflection based, you only have the really interesting ones in source code to care about
- watwut 2y agoThose sux when maintaining, investigating and debugging code. They break IDE functionality too. You can't put breakpoints in them. You don't see them properly in views. It is trading off useless aesthetics over practicality.