# Mocking magic (it's difficult)

In my earlier post I presented the basic idea behind the new implementation of my WordPress adapter classes consisting in using PHP magic methods to create wrapping methods in the adapter classes.

## Not a new idea

It looks like my idea is not a new one and it’s often used and though this is not helping my self-esteem it sure tells me I’m not utterly wrong.
What I’m gaining using magic methods is that I won’t have to maintain a long list of adapter methods that will need to be updated for different WordPress versions, plugins and themes.
What I’m losing is the ability to mock the adapters.

## The original purpose is lost

I’m trying to get around the problem and via some experimentation I’ve understood I’ve over-estimated PHPUnit mocking capabilities in a wrong leap of faith.

## You can’t mock thin air

PHPUnit stubbing works, to my understanding, like this:

The mocker (here PHPUnit_Framework_TestCase) goes to a restaurant (the class to mock) and asks for a menu of the available plates (public methods); the mocker will then make-up a restaurant façade (the mock class) that serves plates (mocks) that only contain a picture of the original one (the signature) but actually contain nothing (return null).

Mocking works instead, again to my understanding, like this:

The mocker (here PHPUnit_Framework_TestCase) goes to a restaurant (the class to mock) and asks for a menu of the available plates (public methods); the mocker will then make-up a restaurant façade (the mock class) that serves the same plates (mocks) as the restaurant because, when a customer orders one (invokes a method), the cook will really go to the original restaurant to have the plate cooked (maintains the same logic of the original method) hence the plates look the same (same signature) but some (the really mocked methods) will be different in some way (return different values).

## The problem with a restaurant that serves no plates (but can prepare any)

What happens here is that the adapter classes using the __call magic method to wrap global functions at run-time do work like a restaurant but this way:

The mocker walks into the restaurant (the class to mock) and asks for available plates (public methods) and he gets the following answer "We do not have any available plates but anything you ask we can prepare (create at run-time) if its made of something edible (if the wrapped function exists).".
The mocker gets out of the restaurant, builds a façade(the mock class) and when someone asks for plates answers "We do not serve any plate (mock method), don't know how they look (the method signature) and can't prepare them.".

It’s an empty façade.

## Write down some plates now and then

The first solution I came up with is to use either the activate or the deactivate hook to dump the currently defined WordPress functions and store them for testing time.
Being in the admin area even gives me the edge to have all the admin functions at my disposal and make a way richer dump.
Will try and see.