I would argue not removing POJO for test coverage stats. Because it may flesh out unused getters or setters that can be removed.
Even if let’s say that an accessor method is never directly referenced by your code, and is only access through some marshalling/unmarshalling of JSON or DB Rows, then that may just mean that you dont have enough test on the marshalling/unmarshalling logic
Focus. It's not about that it's referenced by marshalling, or reflection in general, but about not being a part of direct code base. They are generated by the compiler.
There are reasons for providing 70%-80% on code coverage, and agreement on not testing POJO is one of them.
I think that in general you have to rethink WHY people write tests, or even TDD, and why they they don't.
Also, what are the drawbacks of having 100% coverage.
Please note that coverage doesn't guarantee that your code will be bug free, and instead of focusing on scoring coolness points, focus on bugs coming from misuse of programs logic, faulty incoming data and concurrency.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I would argue not removing POJO for test coverage stats. Because it may flesh out unused getters or setters that can be removed.
Even if let’s say that an accessor method is never directly referenced by your code, and is only access through some marshalling/unmarshalling of JSON or DB Rows, then that may just mean that you dont have enough test on the marshalling/unmarshalling logic
Focus. It's not about that it's referenced by marshalling, or reflection in general, but about not being a part of direct code base. They are generated by the compiler.
There are reasons for providing 70%-80% on code coverage, and agreement on not testing POJO is one of them.
I think that in general you have to rethink WHY people write tests, or even TDD, and why they they don't.
Also, what are the drawbacks of having 100% coverage.
Please note that coverage doesn't guarantee that your code will be bug free, and instead of focusing on scoring coolness points, focus on bugs coming from misuse of programs logic, faulty incoming data and concurrency.