1.3.2. Visitable Mock Objects

1.3.2. Visitable Mock Objects
Prev	1.3. Advanced Expectations	Next

To obtain a visitable mock object you must:

Derive and define your object with the methods you need
Create a controller for each method and set up the behaviour
Activate and use the object

The following listing contains a short example and explains the basic features.


  class MyInterfaceClass 
  {
    public:

     virtual int access(unsigned &index) = 0;
  }

  class MyVisitableMockObject : public VisitableMockObject,  
                                public MyInterfaceClass
  {
    public:

      MyVisitableMockObject(const String &name)
        : VisitableMockObject(name, 0)
        , MOCKPP_CONSTRUCT_MEMBERS_FOR_VISTABLE1(access) 
      {}

      MOCKPP_VISITABLE1(MyVisitableMockObject, int, access, unsigned); 
  };

  MyVisitableMockObject mvo("mvo");

  MOCKPP_CONTROLLER_FOR(MyVisitableMockObject, access) access_ctr (&mvo); 

  access_ctr.addThrowable(std::string("throw"), 2); 
  access_ctr.addResponseValue(1, 13); 
  access_ctr.addResponseValue(2, 37);
  access_ctr.addResponseValue(3, gt<unsigned>(50)); 

  mvo.access(1); 
  mvo.access(13);
  mvo.access(lt<unsigned>(123)); 

  mvo.activate(); 

  // use the object

  mvo.verify();

	Define your interface class.
	Derive your mock object class from `VisitableMockObject` and the interface class.
	According to the type of method and the number of parameters it takes add a macro that does the construction part for all the necessary internal helper variables for that method.
	Similarly add another macro that implements the method with it's internal variables and helper methods.
	Create a controller object for the method to set up it's behaviour.
	Add some behaviour: tell the object to throw an exception when called the first and second time.
	More specific behaviour: depending on the parameters passed it shall respond with certain return values.
	The former controller parameters where strict and demanded exact equality. By using constraint objects it is possible to use arbitrary tolerance. In the example the parameter must be greater than 50 to return 3.
	Describe the expected execution path and the expected parameters for the method how it shall happen in your test later. This is simply done by calling the methods.
	Demands that the parameter value is less than 123.
	Activate the object and use it in the tests.
	After the tests have completed verify all conditions that are still pending, for example unused return values or exceptions.

For a deeper documentation of the methods involved with a controller see the api documentation of VisitableMockObject::Controller.

1.3.2.1. Dispatching Order

The expectations are evaluated in the following order which of course also depends on the method definition itself. Parameters to the method can only be evaluated if they exist and void methods obviously can't return any objects.

verify that the expected method is called
find and throw an exception based on the parameters passed
if available: throw the next exception from the list created with addThrowable()
throw the default exception if defined
verify the values of the parameters passed
find and return an object based on the parameters passed
if available: return the next object from the list created with addReturnValue()
return the default object

There is a subtle difference in the behaviour of versions before 1.2.x which affects topics 3. and 7. in the above list. Older versions always checked if there is an exception available and threw them in the call. Newer version on the contrary use the order from the sources.

For example take the following code fragment:


  mock.addThrowable(xx);
  mock.addReturnValue(aa);
  mock.addThrowable(yy);
  mock.addReturnValue(bb);

In this case older versions would behave as follows:

throw(xx)
throw(yy)
return(aa)
return(bb)

Newer versions on the other hand will do what is written in the code:

throw(xx)
return(aa)
throw(yy)
return(bb)

If your code relies on the old behaviour you can switch back by calling unsetThrowablesInline(). This method is available for the controller object and only influences the according method. Additionally the method is also available in the container mock object itself and affects all registered sub-objects.