Quote Originally Posted by nlif View Post
Good point. I was waiting for someone to bring it up This argument is a good one, and it came up in our internal discussions as well. The counter-argument was, that I may want to test other components, that use my domain object as input, and verify that they can handle incorrect data. But I am not sure that the counter-argument is valid: after all, if there is absolutely no way to construct an object in a certain way, then nobody will ever get it as input...
I don't think the counter-argument is valid.
If you can't construct an object in a certain way then you can't, you don't need those tests ...

Quote Originally Posted by nlif View Post
I will explain: let's say that a domain object has a state property. This is saved in the database, and needs to be populated when the object is loaded by Hibernate. However the state is only used by the object itself, so there is no setter and no getter. The object transitions across its state-space in response to events, but no-one can change the state from outside. No one can query on the state , either. Or, at least, not using a getter (i.e. I can ask isFinished(), and get true or false, but not getState(). Therefore, there are no setter or getter, but there is a need to test that the Hibernate mapping is correct. I hope this clarifies it for you.
Yes, this one is trickier.
Do you have an isFinished()-like method for every state?
If you do, you could use those methods to test the population.
My point is that you should probably try to test through the object's public interface. Every test that knows about the implementation details of your class will break if you change the implementation.

You might use the state just internally in the object, but your object probably acts in a different way in different states. There must be some noticable difference for the outside world, otherwise you wouldn't need the internal state. So could you test those differences visible for the outside world?


Tamas