[nsxwolf]

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]

Heh, 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]

getter setters w/o buisness logic seem like an antipattern though. let spring or some other annotation handle those

[watwut]

Those 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.

[lesuorac]

Eh, whats the difference between spring auto-generating them at build time via an annotation or an IDE auto-generating them at write time?

[hsbbxbyb]

IDE 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

[cuteboy19]

coverage is not affected