at that point what are you testing? allocation/deallocation? Nothing is actually happening unless you depend on constructors/destructors when you use reflection to gen a mock type or real value type to inject. Or do you mean just assert true that all getters are not null?

I agree that unit testing for the sake of KPI's is the wrong approach and unit testing functionality (as a means of documenting it, proving it still works as intended) is far better.

> at that point what are you testing?

Memory.

> Nothing is actually happening unless you depend on constructors/destructors when you use reflection to gen a mock type or real value type to inject.

Just get an object from IoC container, then test that getFoo() == getFoo(setFoo(getFoo())) for every Foo with get and set methods, so you will have 80% of coverage for those getters and setters. For read-only properties, just get value and throw it away.

> I agree that unit testing for the sake of KPI's is the wrong approach and unit testing functionality (as a means of documenting it, proving it still works as intended) is far better.

Unit tests are for proving correctness of logic in a unit of code. Data structures are not logic. IMHO, such trivial parts of program should be ignored by coverage tool, but topic starter said that they cannot change rules. :-/

> > at that point what are you testing?

> Memory.

In unit testing, the "memory" is not the system under test though.

>> at that point what are you testing? > Memory.

It doesn't make sense to test something you have no control over, if the OS fails to allocate memory there's nothing you can change in your code to fix that.

Likewise, if you're improperly instructing the OS to allocate memory (via some constructor or factory or whatever) there is no test you can write to test your own intentions that won't be subject to exactly the same level of incorrectness as the implementation code itself. If you've written "do the thing" writing a "test" that says "hey make sure I wrote 'do the thing'" is ridiculous.

I've often found this to be a matter of semantics. Someone will say they're writing a "unit test" and load all the assertions and logic associated with the meaning of "unit test" into their brain and then try to apply it in a way that subtly invalidates those assertions when they start writing.

To make things worse, there's a cultural disinclination toward "semantic arguments" so you end up arguing with people that have basically no chance of understanding why what they're doing doesn't provide the value it should

You shouldn't have setters in the first place. What's the point of encapsulation if anyone can just set properties at will?

Sometimes the value you pass to a setter can go through additional logic to determine the final value to be set e.g.:

    private int value1;

    private int value2;

    public void setValue2(int value2) {
        this.value2 = value2;                  
    }
    
    public void setValue1(int value1) {
        if (this.value2 > 0) {
            this.value1 = value1 + this.value2;
        } else {
            this.value1 = value1;
        }
    }

Obviously this is a contrived example but if you have logic other than a simple "this.value = value", then you might want to unit test that bit.

Also useful if you want to add logging, or capture some metrics, or set a breakpoint.

Ah, the sound of people not using their type system properly.

Parse, don't validate.

But also don’t create AggregateNonNegativeInteger type when generics will do.

Simplest solution? Don’t have any setters.

Removing them would reduce your coverage percentage.

Good thing. It shows that a % of your tests were actually not targeted at the most important areas of the code base

I had to do it in one project. It's not trivial, but also not too difficult. Getters were easy, setters required different types of values. After handling various date type values for setters it worked fine. Occasionally I would see an exception for fields generated by APIs like Lombok, which needed to be excluded from my setter list.

I didn't like that I had tobdo it, but it was easier than getting several approvals to get Sonar rules changed.

Or stop using the broken pattern of getters and setters

I ask interview candidates to explain why they’re using getters or setters. They never have a reason.

Let's say you have a type. Let's call it List.

When you create a List you want to enable the possibility of setting a Capacity - how large can this List be.

And you also want to enable reading how large the List is at a given point.

Pretty valid case for a setter and a getter in my book.

Would "because it's conventional and most tools and developers assume them" be an acceptable answer? The reason I read is "because you might wanna change the implementation" but honestly it's seems very rare to need to do that

Because your data structure and your API are separate things and generally speaking, the data structure should be opaque to users of that structure unless it's sole purpose is as a record for a bunch of request arguments. For those fat request structures, it ends up being a lot of noise indeed, but in any case most of those structures for most people are dealt with by deserialization and you can often skip generation of setters and getters or autogenerate them.

Do you want to return a copy/clone of the inner object or just let people mutate it, destroying all of your data structure's invariants? Yes, if you change the implementation of the structure, user code will also break and it is certainly easier to do that behind a method, this is indeed rare in practice but the nuisance of migrating direct access to indirect access is bigger than the nuisance of (today's) unnecessary indirection.

Since in some cases safety around invariants and future proofing will require the level of indirection, it is easier to just expect the convention. Moreover, codegen can just produce them for you, they can be excluded from test coverage. Then there are languages like python that allow you in the future to pretend that indirect access is direct access and cannot protect invariants in any case, so just go direct from day one.

Yeah, that's the textbook explanation, I guess. So I'll stick to it in interviews, as useless it is in real life.

All the hoops for this... Codegen, excluding from coverage, Lombok, and all that magic to hide you from a simple obj.field that is all you're doing in 99.9% of cases. It's just so rare in practice. I think the language itself should allow for readonly fields and property setters for the extremely rare occasions where you need this.

The correct solution is not having either. Getter/setters are effectively an anti pattern as they support needless mutability but worse they add nothing of value.

As a general rule most fields should be initialized in the c-tor, and they should be final.