Mocking values in TDD

问题:

In the book GOOS. It is told not to mock values, which leaves me confused. Does it means that values don't have any behavior?

I dont' much knowledge about the value object but AFAIK the value objects are those which are immutable. Is there any heuristic on deciding when to create a value object?

回答1:

Not all immutable objects are value objects. By the way, when designing, consider that the ideal object has only immutable fields and no-arg methods.

Regarding the heuristic, a valid approach can be considering how objects will be used: if you build an instance, invoke some methods and then are done with it (or store it in a field) likely it won't be a value object. On the contrary, if you keep objects in some data structure and compare them (with .equals()) likely you have a value object. This is especially true for objects that will be used to key Maps

Value objects should be automatic-tested themselves (and tests are usually a pleasure to read and write because are straightforward) but there's no point in mocking them: the main practical reasons for mocking interfaces is that implementation classes

• are usually difficult to build (need lot of collaborators)
• are expensive to run (access the network, the filesystem, ...).

Neither apply to value objects.

回答2:

Quoting the linked blog post:

There are a couple of heuristics for when a class is not worth mocking. First, it has only accessors or simple methods that act on values it holds, it doesn't have any interesting behaviour. Second, you can't think of a meaningful name for the class other than VideoImpl or some such vague term.

The implication of the first point, in the context of a section entitled "Don't mock value objects", is that value objects don't have interesting behaviour.