You are insisting on testing a thing, that might belong to someone else, right? (client code assumption) well, you should test YOUR code, not 3rd party.
You stated that there might be additional logic in getter/setter. Or that there might be a bug in getter. This is serious claim, specifically in times when getters and setters are generated by IDE or directly the compiler (thanks to lombok).
I attempted to test getters and setters once. I did it with reflection, scanned for all of them and tested for primitives and boxed primitives. Goal was to drastically increase coverage stats and it proved to my coworker that there was no point for it. After that team agreed to remove POJO from coverage stats.
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.
You are insisting on testing a thing, that might belong to someone else, right? (client code assumption)
Actually, no. If "a thing" exists in your codebase, and that thing is a POJO, then it is being used by you, by some other thing in your codebase. Your code is the client code.
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.
You are insisting on testing a thing, that might belong to someone else, right? (client code assumption) well, you should test YOUR code, not 3rd party.
You stated that there might be additional logic in getter/setter. Or that there might be a bug in getter. This is serious claim, specifically in times when getters and setters are generated by IDE or directly the compiler (thanks to lombok).
I attempted to test getters and setters once. I did it with reflection, scanned for all of them and tested for primitives and boxed primitives. Goal was to drastically increase coverage stats and it proved to my coworker that there was no point for it. After that team agreed to remove POJO from coverage stats.
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.
Actually, no. If "a thing" exists in your codebase, and that thing is a POJO, then it is being used by you, by some other thing in your codebase. Your code is the client code.