title: Don’t mock value objects: too generic rule without explanation
body: <p>Here is a quote from Mockito unit testing framework: </p>
  
  <blockquote>
    <p>Don't mock value objects</p>
    
    <p>Why one would even want to do that?</p>
    
    <p>Because instantiating the object is too painful !? => not a valid
    reason. If it's too difficult to create new fixtures, it is a sign the
    code may need some serious refactoring. An alternative is to create
    builders for your value objects -- there are tools for that, including
    IDE plugins, Lombok, and others. One can also create meaningful
    factory methods in the test classpath.</p>
  </blockquote>
  
  <p>And another quote from <a href="http://www.mockobjects.com/2007/04/test-smell-everything-is-mocked.html" rel="noreferrer">here</a>:</p>
  
  <blockquote>
    <p>There isn't much point in writing mocks for simple value objects
    (which should be immutable anyway), just create an instance and use
    it.  It's not worth creating an interface / implementation pair to control which time values are returned, just create instances with the appropriate values and use them. 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.</p>
  </blockquote>
  
  <p>This seems to be a valid reason for dumb value objects holding just the values and nothing more, but things getting more complicated when you have a ValueObject referencing the entities and other value objects.</p>
  
  <p>Let's say I have Person and Pet objects which are entities and Relationship (owner, doctor, etc) which is a ValueObject between two persons and has a RelationshipType which is also a Value Object. So, relationship is basically:</p>
  
  <pre><code>class Relationship {
      private Person person;
      private Pet pet;
      private RelationshipType type;
  }
  </code></pre>
  
  <p>Now, let's say I have a class with the predicate like isOwnerRelationship, isDoctorRelationship, whatever. Basically predicate is as simple as </p>
  
  <blockquote>
    <p>relationship -> relationship.isOwner(); //delegates to relationshipType.isOwner()</p>
  </blockquote>
  
  <p>Now, I want to test the predicates and I have two options:</p>
  
  <p><strong>Mock Relationship</strong></p>
  
  <pre><code>public void testIsOwner() {
     Relationship rel = mock(Relationship.class);
     when(rel.isOwner()).thenReturn(true);
  
     assertTrue(RelationshipPredicates.isOwner(rel));
  }
  </code></pre>
  
  <p><strong>Don't mock Relationship</strong></p>
  
  <pre><code>public void testIsOwner() {
     Person person = PersonBuilder.newPerson();
     Pet pet = PetBuilder.newDogPet();
     RelationshipType type = RelationshipTypes.ownerType();
  
     Relationship rel = new Relationship(person, pet, type);
  
     assertTrue(RelationshipPredicates.isOwner(rel));
  }
  </code></pre>
  
  <p>Of course the example is over simplified because for a person you may be required to provide address, for Pet you may have to provide BreedType, whatever, i.e. transitive graph of entities and value objects you may need to provide can be very huge. Of course you can mock Entities, but assume you have more ValueObjects of ValueObjects inside of Relationship. Even if you have fancy builders, you will have to provide each and every part of the original ValueObject even though unit test is going to test only single aspect of it.</p>
  
  <p>In the predicates test, why should I care about full object construction if the predicate cares about calling one particular method of the object or combination of them? </p>
  
  <p>Or is such <em>value object</em> can't be considered as a <em>simple</em> and rule doesn't apply?</p>