Mockery Terminology: Any Suggestions From The Audience?
Mockery is my Mock Object Framework for PHP 5.3, geared towards replacing existing mock object solutions (like PHPUnit Mock Objects) with a simpler, more flexible and more intuitive alternative with a fuller feature set. All that aside, this blog post is about some of the features Mockery 0.7 will add shortly. When I set out to write Mockery, I did so knowing that I’d need to settle on some new terminology. Here’s what I came up with:
1. Partial Mocks
This is the least debateable term since it’s adopted by other Test Double frameworks. A partial mock is a mock object where only some methods are mocked. The non-mocked methods continue to behave as defined in the class being mocked. It’s mainly useful where you only want to create a mock object which simulates a concrete implementation of an abstract class (in the absence of an existing concrete class).
2. Proxy Mocks
In writing Mockery I was faced with a dilemna when it came to classes and methods marked final. You can’t override such classes so the normal mocking implementation just doesn’t work. To resolve this and force the mocking of final methods, I settled on using the Proxy Pattern, thus the term Proxy Mock. The implementation is straightforward. Since we can’t override final methods/classes – we don’t. We ask the user to instantiate an actual of that type and pass it into Mockery. Mockery then embeds the object into a Proxy class, which can intercept method calls to the real objects and replace those methods with alternative behaviours (i.e. mock expectations). This is a simple way to mock final methods. Of course, it comes with a price – the Proxy won’t carry the real object’s type. And people wonder why I really don’t like the final keyword in PHP…
3. Alias Mocks
An Alias Mock is based on using class_alias() in PHP 5.3. The concept was to allow mocking of static methods by aliasing the class hosting the static methods, the alias being a mock object class. It works best in an autoloading scenario coupled with unit test process isolation. The next term will explain the main reason why aliasing was ceased upon as something worth including.
4. Instance Mocks
The real reason why Alias Mocks were created. An instance mock refers to a mock object class created as an alias to a real class. This basically is a cheap method of intercepting the “new” keyword without resorting to PHP extensions. All attempts to instantiate the real class, will instead provide an instance of the mock object alias. Again, it works best with autoloading (require_once calls would create a fatal error).
If you still don’t understand some facets of these – the Mockery README on github.com is a good place to see the API in action for these.
My question to readers is whether these four terms are acceptable? It’s hard to trust any single individual (i.e. me) to dream up appropriate terms, so feel free to offer suggestions or alternatives in the comments.