I don't get it why there are so many people out, that think testing stupid model classes with getters and setter is needed.

Dude. There is no logic in this class ... it's pure data that gets not modified there (well except if you call the setter)

I've wasted way too much time writting useless unit test because some ppl want to masturbate on 100% code coverage 🤦🏻‍♂️

I use a trait to test getters and setters through reflection, works nicely and the code coverage is nice 😛

These are data structures, there's nothing to test...

What you should do is to test them indirectly, i.E. Through test cases testing services using them.

@netikras except for a few special getters ofcourse, like getAmountOfComments or something in that sense

@alexbrooklyn why?

@netikras I once faced a situation where the special logic in a certain getter was incorrect due to a brain fart, the test ensured that I configured everything properly

Sure i could've done it through a functional test by checking the output of the page, but that seems like a lot of effort to test something that you might not expect to break

The real error is 100% test coverage.

Even if you get it, it does not mean that you test every aspect of the code.

You could still have edge cases where the code chooses the wrong path, or crashes, or computes a bad value or ...

Aiming for 100% risks spending time on useless tests as you have, instead of focusing on identifying hotspots where different values in a range can be of utter importance, like price calculations, or unit conversion, meter vs feet ;), that can make a big impact :D

@alexbrooklyn why do your data structures have logic in them?

"but that seems like a lot of effort" <-- but that's how you have decent coverage :)

frankly I prefer a mixture of unit-integration tests. I mock more complex dependencies [and test them separately] and test all the service calls, which underneath tests other things, like getters, setters et al. Like you do with tdd. Pure unit tests only testing a single method scope [w/o deps] seem like a waste of time and I don't see a point in that.

After all, if it is impossible to reach a unit with some service call, why is that unit even there? :)

@Voxera exactly. But aiming for 95+% is a good thing.

If you have 100, you have bugs in your code. I mean how the hell does one cover ioexceptions' handling caused by network calls by unittests? 😁 timeouts? DB errors [tx rollbacks]? Exception handlers in @Controller and stuff like that? :)

if you have 100% coverage you prolly do not have proper error handling

@netikras Some of my methods use values from within the data structure to calculate something, I don't think that's weird though

Like getFullName() that uses the firstname and lastname

@alexbrooklyn maybe.. I'd have a formatter for that :) or set fullName as a field and keep it a pure dumb data structure

@netikras or you mock the network layer code to trigger those exceptions to ensure you catch them.

Thats actually one thing you should do if network access is vital and you depend on correct error handling.

But in any large code base you will most likely have dome generated code, for example webservice or rest proxys where not all methods are used and where building unit tests does not add much value.

If you use TDD you should end up with close to 100% but if the code base started out without tests, take it in steps, focusing on parts where you have had a lot of regressions.

So sad, I almost cry reading this.

An engineer so stupid he cannot create a script/automatic template to create those test classes automatically.

Dude, u deserve what u got