Unit-Testing of Domain Objects and Encapsulation

[szabtam]

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

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

[nlif]

Tamas,

Here's an interesting quote I found in JUnit Recipes/J.B.Rainsberger, which I think says the same, but in a more generalized form. Although we're getting just a tad bit philosophical here, I think this is an important principle. What's left, I guess, is just see how to apply it to concrete cases...

1.3.2 Test behavior, not methods
This brings us to another recommendation when writing tests: your tests should
focus on the behavior they are testing without worrying about which class is under
test. This is why our test names tend to be verbs rather than nouns: we test behavior
(verbs) and not classes (nouns). Still, the difference between behavior and methods
might not be clear: we implement behavior as methods, so testing behavior
must be about test methods. But that’s not entirely true. We do implement behavior
as methods, but the way we choose to implement a certain behavior depends on a
variety of factors, some of which boil down to personal preference. We make a
number of decisions when implementing behavior as methods: their names, their
parameter lists, which methods are public and which are private, the classes on
which we place the methods, and so on—these are some of the ways in which methods
might differ, even though the underlying behavior might be the same. The
implementation can vary in ways that the tests do not need to determine.
Sometimes a single method implements all the required behavior, and in that
case, testing that method directly is all you need. More complex behaviors require
the collaboration of several methods or even objects to implement. If you let your
tests depend too much on the particulars of the implementation, then you create
work for yourself as you try to refactor (improve the design). Furthermore, some
methods merely participate in a particular feature, rather than implement it. Testing
those methods in isolation might be more trouble than it is worth. Doing so
drives up the complexity of your test suite (by using more tests) and makes refactoring
more difficult—and all for perhaps not much gain over testing the behavior
at a slightly higher level. By focusing on testing behavior rather than each
individual method, you can better strike a balance between test coverage and the
freedom you need to support refactoring.

[karldmoore]

Philosophical Unit testing, sounds like a good book, I'd buy it .

[szabtam]

Yes, the quote says the same thing and it is much more detailed...after all it is a book not just a post on a forum :-)

The idea isn't something new, it has been formulated by most of the guys involved in Test Driven Development.

Hopefully, you can apply the idea to your scenario...

Take care,

Tamas