4 ms·

> 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 m

> 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. :-/

growse 3y ago
> > at that point what are you testing? > Memory. In unit testing, the "memory" is not the system under test though.
zarathustreal 3y ago
>> 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
Mawr 3y ago
You shouldn't have setters in the first place. What's the point of encapsulation if anyone can just set properties at will?
- noisy_boy 3y ago
  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.
  - tom_ 3y ago
    Also useful if you want to add logging, or capture some metrics, or set a breakpoint.
  - growse 3y ago
    Ah, the sound of people not using their type system properly. Parse, don't validate.
    - reactordev 3y ago
      But also don’t create AggregateNonNegativeInteger type when generics will do.

growse 3y ago

> > at that point what are you testing? > Memory. In unit testing, the "memory" is not the system under test though.

zarathustreal 3y ago

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

Mawr 3y ago

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

noisy_boy 3y ago
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.
- tom_ 3y ago
  Also useful if you want to add logging, or capture some metrics, or set a breakpoint.
- growse 3y ago
  Ah, the sound of people not using their type system properly. Parse, don't validate.
  - reactordev 3y ago
    But also don’t create AggregateNonNegativeInteger type when generics will do.