Sometimes I think my readers must get terribly bored with my one track entries – I seem to roll through phases: a few weeks of OpenID, then a few of PHPSpec, then a detour for several months on X . That’s what you get for reading an open source developer’s weblog – we can only really work on one thing at a time so there’s a lack of variety.
Anyway, after that minor detour, this one’s a brief notice that we’ve commenced work (as of a while ago really) on PHPMock.
If you remember, I had one of those long winded blog posts about Mock Objects and Stubs in SimpleTest/PHPUnit and PHPT. Now that I’ve really launched into PHPSpec development, I’m finding a few spots here and there where my attention levels drop and I need a diversion. Which means PHPMock is seeing activity – there’s a whole branch written over a few days to get an API discussion going between developers.
The purpose of PHPMock is to write an independent Mock Object/Stub framework – something you can use in any scenario or xDD approach – from a PHPUnit Unit Test, to a PHPSpec Spec, to a PHPT test file. SimpleTest isn’t left out either – PHPMock is self contained so it should travel well.
Once we get over the Mock vs Stub approach question to such a framework (Are Mocks complicated Stubs, or Stubs simplified Mocks?) we’ll have a firm design and an API to develop with. I’m currently favouring an API in a simple readable form, e.g.
[geshi lang=php]// setup
$mockPerson = PHPMock::mock(‘Person’);
$mockPerson->shouldReceive(‘hasName’)->withNoArgs()->once()->andReturn(false);
// implemented use case
$mockPerson->hasName(); //FALSE
// verification of Mock expectations
$mockPerson->verify(); //TRUE[/geshi]
Not sure if it will stay that way, have some alternate API appended (less verbose), or end up as something different. I’ll let you know.
A good feeling about this small project is that we have peers checking in. Sebastian Bergmann for PHPUnit, me for PHPSpec, and Travis Swicegood for PHPT and maybe SimpleTest. So at least it’s not just me rumbling around enforcing my divine will .
If you want to look around the experiemental branch code, we’re hosted over at http://code.google.com/p/phpmock/.
reference : http://blog.astrumfutura.com/2007/11/phpmock-independent-mock-objectstub-framework/
2011年1月2日 星期日
The Mockery: PHP Mock Objects Made Simple
As I explored in my previous post, PHP Mock Objects: Sucking Ass Since Forever, Mock Objects in PHP have had difficulty gaining traction. One of the targets of this examination (in between variations of “I love PHPUnit”) was PHPUnit’s Mock Objects implementation. My main point, I suppose, was that with PHPUnit being the de-facto standard for unit testing, its mock objects implementation left a lot to be desired. As the later comments suggested, suger coating the situation won’t change the fact I’m criticising one of the most deeply embedded libraries in PHP practice (well, actually a teeny tiny bit of it).
So what is Mockery? Mockery is a mock object framework. You can use it to mock, stub and dazzle your classes into submission – even when they don’t exist yet . Mock objects are almost a given when it comes to Test-Driven Development, but even non-TDD unit testing can use mocks and stubs. They encourage test isolation, stand in for classes you haven’t implemented yet, and can replace resource intensive tasks with mocked versions (since we like our tests to run really fast). Using Mock Objects (or Stubs) is just incredibly useful.
So what does Mockery offer you, the unit tester?
1. It integrates with pretty much any conceivable testing framework with almost no effort.
2. It’s simple to use, intuitive, and specifically works with the language we use to describe object interactions.
3. The API is uncluttered and minimal.
4. Flexibility is its cornerstone allowing it to accurately and succintly express your requirements.
5. It enables simple one-off setups that can be later modified so you don’t need to re-specify entire mocks for every single test.
6. If you use Ruby and PHP, it will make your day (yes, I also write Ruby – sue me).
Why consider it instead of PHPUnit’s or (insert PHP testing framework)’s mock object implementation?
1. It ports to ANY testing framework with zero effort
2. It isn’t inspired by Java
3. It has no gotchas, requirements for custom callback code, or complicated and frustrating setups.
4. It’s capable of mocking real objects and performing mock object recordings of existing processes.
5. Expectations are not pre-constrained – you hold the rope.
Time for the inevitable API exploration… Mockery is written for PHP 5.3, so get your namespace booties on. If you cannot currently adopt PHP 5.3, read along anyway. You’ll be using PHP 5.3 eventually .
You can find Mockery on Github at http://github.com/padraic/mockery. Besides the code, there is one massive README that will go into the API and usage in far more detail than I can do in this article. It is currently not released to a PEAR channel, but I’ll be doing so once I feel happy that the framework has enough hard-core crazy features to last its lifetime in PHP. You can, however, clone from the git repository and install it via PEAR using the included package.xml file. I love issue reports – if you have them, don’t be stingy and keep them to yourself.
For those who find themselves curious about how, specifically, Mockery pits against PHPUnit Mock Objects, I’ll run a later article contrasting the two in terms of features and examples.
The basis of Mockery’s API is the English language. It’s a Domain Specific Language (DSL) in the form of a fluent interface. Given that basis, it’s not surprising that Mockery’s intent is to capture every possible object expectation within a DSL statement that reads like English.
For example, let’s assume we have the class Engineering which is utilised by the class Starship. Hey, I wrote a whole article based on a dodgy Klingon once so get with the programme. We’re testing the Starship class, and find that there is no Engineering class…yet. So we shrug, and decide to use a mocked object to replace Engineering. One of the consequences of this approach is that, down the line, the mock usage will actually specify the API our real Engineering class should use (this is test-driven DESIGN, afterall).
To boot up the creative juices, we start with a story:
Given our Starship has located a planet, it will instruct Engineering to turn off the warp drive, and then to divert 40% power to sensors, and then to divert 20% power to auxilliary engines, and finally to run a Level-1 diagnostic on itself. All instructions must be given once in this precise order. There may optionally be many diagnostic runs of any Level at any stage in the process. The Starship must report whether the operation was successful. Success is measured by successfully passing a Level 1 diagnostic.
Okay, so what exactly are we expecting?
[geshi lang=php]use \Mockery as M;
require_once ‘Starship.php’;
class StarshipTest extends PHPUnit_Framework_TestCase
{
public function testEngineeringResponseToEnteringOrbit()
{
$mock = M::mock(‘Engineering’);
$mock->shouldReceive(‘disengageWarp’)->once()->ordered();
$mock->shouldReceive(‘divertPower’)->with(0.40, ‘sensors’)->once()->ordered();
$mock->shouldReceive(‘divertPower’)->with(0.30, ‘auxengines’)->once()->ordered();
$mock->shouldReceive(‘runDiagnosticLevel’)->with(1)->once()->andReturn(true)->ordered();
$mock->shouldReceive(‘runDiagnosticLevel’)->with(M::type(‘int’))->zeroOrMoreTimes();
$starship = new Starship($mock);
$this->assertTrue($starship->enterOrbit());
}
public function teardown()
{
M::close();
}
}[/geshi]
There’s the test. Our mock has been setup according to the expectations implicit in the feature story. As you might notice, the final diagnostic calls are unordered (can occur at any time between ordered calls). For PHPUnit, the teardown() method is optional if you configure PHPUnit to use the bundled TestListener. I added it to show that it’s the sole integration needed with a testing framework (unless using the bundled TestListener for PHPUnit).
Now let’s write just enough code to pass this test in Starship.php:
[geshi lang=php]class Starship
{
protected $_engineering = null;
public function __construct($engineering)
{
$this->_engineering = $engineering;
}
public function enterOrbit()
{
$this->_engineering->disengageWarp();
$this->_engineering->runDiagnosticLevel(5); // unordered call!
$this->_engineering->divertPower(0.40, ‘sensors’);
$this->_engineering->divertPower(0.30, ‘auxengines’);
$criticalResult = $this->_engineering->runDiagnosticLevel(1);
return $criticalResult;
}
}[/geshi]
Hurrah! The test passes. We’ve just tested Starship without needing a real Engineering object (or even a class of that name!). You can find this example in the examples directory on Github for Mockery, along with the phpunit.xml configuration and Bootstrap.php file used.
If something did go wrong with our expectations, Mockery would throw an Exception to complain about it.
The Mockery API also handles return values (including a return queue for multiple method invocations with the same arguments), of course, along with a host of other features and expectation term methods. Refer to the README up on Github. Like I said before, it’s very complete and informative. We’ve barely touched on the basics of Mockery in this article, so get reading.
reference : http://blog.astrumfutura.com/2010/05/the-mockery-php-mock-objects-made-simple/
So what is Mockery? Mockery is a mock object framework. You can use it to mock, stub and dazzle your classes into submission – even when they don’t exist yet . Mock objects are almost a given when it comes to Test-Driven Development, but even non-TDD unit testing can use mocks and stubs. They encourage test isolation, stand in for classes you haven’t implemented yet, and can replace resource intensive tasks with mocked versions (since we like our tests to run really fast). Using Mock Objects (or Stubs) is just incredibly useful.
So what does Mockery offer you, the unit tester?
1. It integrates with pretty much any conceivable testing framework with almost no effort.
2. It’s simple to use, intuitive, and specifically works with the language we use to describe object interactions.
3. The API is uncluttered and minimal.
4. Flexibility is its cornerstone allowing it to accurately and succintly express your requirements.
5. It enables simple one-off setups that can be later modified so you don’t need to re-specify entire mocks for every single test.
6. If you use Ruby and PHP, it will make your day (yes, I also write Ruby – sue me).
Why consider it instead of PHPUnit’s or (insert PHP testing framework)’s mock object implementation?
1. It ports to ANY testing framework with zero effort
2. It isn’t inspired by Java
3. It has no gotchas, requirements for custom callback code, or complicated and frustrating setups.
4. It’s capable of mocking real objects and performing mock object recordings of existing processes.
5. Expectations are not pre-constrained – you hold the rope.
Time for the inevitable API exploration… Mockery is written for PHP 5.3, so get your namespace booties on. If you cannot currently adopt PHP 5.3, read along anyway. You’ll be using PHP 5.3 eventually .
You can find Mockery on Github at http://github.com/padraic/mockery. Besides the code, there is one massive README that will go into the API and usage in far more detail than I can do in this article. It is currently not released to a PEAR channel, but I’ll be doing so once I feel happy that the framework has enough hard-core crazy features to last its lifetime in PHP. You can, however, clone from the git repository and install it via PEAR using the included package.xml file. I love issue reports – if you have them, don’t be stingy and keep them to yourself.
For those who find themselves curious about how, specifically, Mockery pits against PHPUnit Mock Objects, I’ll run a later article contrasting the two in terms of features and examples.
The basis of Mockery’s API is the English language. It’s a Domain Specific Language (DSL) in the form of a fluent interface. Given that basis, it’s not surprising that Mockery’s intent is to capture every possible object expectation within a DSL statement that reads like English.
For example, let’s assume we have the class Engineering which is utilised by the class Starship. Hey, I wrote a whole article based on a dodgy Klingon once so get with the programme. We’re testing the Starship class, and find that there is no Engineering class…yet. So we shrug, and decide to use a mocked object to replace Engineering. One of the consequences of this approach is that, down the line, the mock usage will actually specify the API our real Engineering class should use (this is test-driven DESIGN, afterall).
To boot up the creative juices, we start with a story:
Given our Starship has located a planet, it will instruct Engineering to turn off the warp drive, and then to divert 40% power to sensors, and then to divert 20% power to auxilliary engines, and finally to run a Level-1 diagnostic on itself. All instructions must be given once in this precise order. There may optionally be many diagnostic runs of any Level at any stage in the process. The Starship must report whether the operation was successful. Success is measured by successfully passing a Level 1 diagnostic.
Okay, so what exactly are we expecting?
[geshi lang=php]use \Mockery as M;
require_once ‘Starship.php’;
class StarshipTest extends PHPUnit_Framework_TestCase
{
public function testEngineeringResponseToEnteringOrbit()
{
$mock = M::mock(‘Engineering’);
$mock->shouldReceive(‘disengageWarp’)->once()->ordered();
$mock->shouldReceive(‘divertPower’)->with(0.40, ‘sensors’)->once()->ordered();
$mock->shouldReceive(‘divertPower’)->with(0.30, ‘auxengines’)->once()->ordered();
$mock->shouldReceive(‘runDiagnosticLevel’)->with(1)->once()->andReturn(true)->ordered();
$mock->shouldReceive(‘runDiagnosticLevel’)->with(M::type(‘int’))->zeroOrMoreTimes();
$starship = new Starship($mock);
$this->assertTrue($starship->enterOrbit());
}
public function teardown()
{
M::close();
}
}[/geshi]
There’s the test. Our mock has been setup according to the expectations implicit in the feature story. As you might notice, the final diagnostic calls are unordered (can occur at any time between ordered calls). For PHPUnit, the teardown() method is optional if you configure PHPUnit to use the bundled TestListener. I added it to show that it’s the sole integration needed with a testing framework (unless using the bundled TestListener for PHPUnit).
Now let’s write just enough code to pass this test in Starship.php:
[geshi lang=php]class Starship
{
protected $_engineering = null;
public function __construct($engineering)
{
$this->_engineering = $engineering;
}
public function enterOrbit()
{
$this->_engineering->disengageWarp();
$this->_engineering->runDiagnosticLevel(5); // unordered call!
$this->_engineering->divertPower(0.40, ‘sensors’);
$this->_engineering->divertPower(0.30, ‘auxengines’);
$criticalResult = $this->_engineering->runDiagnosticLevel(1);
return $criticalResult;
}
}[/geshi]
Hurrah! The test passes. We’ve just tested Starship without needing a real Engineering object (or even a class of that name!). You can find this example in the examples directory on Github for Mockery, along with the phpunit.xml configuration and Bootstrap.php file used.
If something did go wrong with our expectations, Mockery would throw an Exception to complain about it.
The Mockery API also handles return values (including a return queue for multiple method invocations with the same arguments), of course, along with a host of other features and expectation term methods. Refer to the README up on Github. Like I said before, it’s very complete and informative. We’ve barely touched on the basics of Mockery in this article, so get reading.
reference : http://blog.astrumfutura.com/2010/05/the-mockery-php-mock-objects-made-simple/
Mockery 0.6 Released – PHP Mock Object Framework
Mockery is a Mock Object framework for PHP, compatible with most unit testing frameworks including PHPUnit. Its purpose is to implement a lightweight grammer for the creation and testing of Mock Objects, Test Stubs, and Test Spies as an alternative to the built-in support offered by PHPUnit, etc.
Mockery is hosted on Github (http://github.com/padraic/mockery) where you can find an extensive README covering its API and uses. The Mockery 0.6 release may be installed from the SurviveTheDeepEnd.com PEAR channel at http://pear.survivethedeepend.com.
Mockery 0.6 features:
- Full Mock Object and Test Stub support
- Lightweight fluent API
- Flexible mocking and stubbing
- Object Interaction Recording
- Natural language syntax and expectation constructs
- Supports generic (untyped) mock objects for rapid prototyping
- Simple partial mocking of real objects
- Both local and global Mock Object call ordering
- Built-in return value queue for repeated method calls
- Support for default expectations
- Support for expectation replacement and stacking
- Fluent API/Law of Demeter mocking
If that sounds complex, it’s not! Mockery can be picked up and used with little study.
Why Mockery?
Mockery’s objective is to simplify Mock Objects in PHP while maintaining significant flexibility and a default level of intuitive behaviour. In Mockery, Mock Objects behave exactly as you write them with liberal interpretations otherwise applied. Mockery was born out of my own need to innovate the use of Mock Objects in PHP and draw away from the original import of aging Mocking approaches from Java. While Java (and almost every other programming language) has been steadily progressing its mock object libraries, and complementing them with new solutions, PHP has a relatively static approach depending on similarly static library components. That result has seen solutions using clunky APIs, poorly described syntax and behaviour, a lack of focus on the practice of using Mock Objects, user confusion, and raised barriers to new programmers trying to learn about Mock Objects. Mockery is one potential solution to these problems. Also, as a dedicated Test-Driven Design user, I really want something that clicks immediately and doesn’t have any gotchas.
Installation
Mockery may be installed from its PEAR channel using:
pear channel-discover pear.survivethedeepend.com
pear install deepend/Mockery
Mockery is written in PHP 5.3 (I know, but all you 5.2 users will get there eventually ). It is released under a New BSD license.
Example
The README offers a good look at some examples, and explains the API in a lot of detail. If you are trying to figure something out, the README undoubtedly has a section for it. Here’s an API example (assuming Mockery namespace used as MK). We’re capturing an interaction where we login into a bookmarking service, check for the existance of a “php” tagged bookmark, add three more bookmarks and then recheck if a “php” tag exists (twice for fun). We’re mocking the service since we don’t actually want to mess with a real account! Following the description closely…
[geshi lang=php]$service = \MK::mock(‘MyService’);
$service->shouldReceive(‘login’)->with(‘user’, ‘pass’)->once()->andReturn(true);
$service->shouldReceive(‘hasBookmarksTagged’)->with(‘php’)->once()->andReturn(false);
$service->shouldReceive(‘addBookmark’)->with(‘/^http:/’, \MK::type(‘string’))->times(3)->andReturn(true);
$service->shouldReceive(‘hasBookmarksTagged’)->with(‘php’)->twice()->andReturn(true);[/geshi]
The example uses some of the basic parts of Mockery to describe some interaction with a mocked web service class (obviously
also stubbing the web service’s responses in terms of booleans). The setup is straightforward, easy to follow, and there’s zero
misinterpretations possible. Our description was likewise simple and uncomplicated. The third line just shows two argument matchers at work, a default regex (intrepreted from any string argument set so long as any eventual string comparison fails and it’s a valid regex) and a Type matcher set to match any valid string.
To put this into some perspective, here’s an equivalent attempt using PHPUnit in a similar order of thought (excerpt from a test).
[geshi lang=php]$service = $this->getMock(‘MyService’);
$service->expects($this->once())->method(‘login’)->with(‘user’, ‘pass’)->will($this->returnValue(true));
$service->expects($this->once())->method(‘hasBookmarksTagged’)->with(‘php’)->will($this->returnValue(false));
$service->expects($this->exactly(3))->method(‘addBookmark’)
->with($this->matchesRegularExpression(‘/^http:/’), $this->isType(‘string’))
->will($this->returnValue(true));
$service->expects($this->exactly(2))->method(‘hasBookmarksTagged’)->with(‘php’)->will($this->returnValue(true));[/geshi]
Besides the differences in API, there are others. If MyService is just intended as a fake unimplemented object (the class doesn’t exist), Mockery carries on and just uses a generic Mock instance without error. PHPUnit will throw an exception, however, stating that login() is not a valid method. If we assume the class is real, but missing some methods, the same thing happens and PHPUnit complains about missing methods. Eventually, you’ll get the idea to implement the dependent class… If we add all the relevant methods (say, we mock an interface with all methods declared), PHPUnit STILL fails. This time complaining that hasBookmarksTagged() was expected only once. This occurs because PHPUnit has no capacity for stacking later expectations, and so, it ignores the second (and any later) ones. We can fix that by merging both into a single expectation using:
[geshi lang=php]$service = $this->getMock(‘MyService’);
$service->expects($this->once())->method(‘login’)->with(‘user’, ‘pass’)->will($this->returnValue(true));
$service->expects($this->exactly(3))->method(‘hasBookmarksTagged’)->with(‘php’)
->will($this->onConsecutiveCalls(false, true, true));
$service->expects($this->exactly(3))->method(‘addBookmark’)
->with($this->matchesRegularExpression(‘/^http:/’), $this->isType(‘string’))
->will($this->returnValue(true));[/geshi]
Using OnConsecutiveCalls() to create a return value queue, and merging the two stacked expectations, allows the PHPUnit variant to pass. Unlike Mockery, if there were ten hasBookmarksTagged() calls, you would need to add all ten return values (Mockery let’s you set the last return value to act infinitely). The merging simply demonstrates that complex class interactions across classes will fall victim to the need to constantly merge expectations until they are unreadable and explain little.
While your mileage may vary, Mockery just doesn’t need reworking, deep thought or extra work. Just state what you want your Mock Object to do in plain unconfused English according to your natural thought order! If nothing else, it helps make the expected interaction obvious which makes your tests more readable and explicit.
Feedback
Any issues can be reported via our Github hosted issue tracker. If you wish to discuss Mockery in more detail, you’re welcome to join the mailing list at http://groups.google.com/group/phpmockery.
reference : http://blog.astrumfutura.com/2010/05/mockery-0-6-released-php-mock-object-framework/
Mockery is hosted on Github (http://github.com/padraic/mockery) where you can find an extensive README covering its API and uses. The Mockery 0.6 release may be installed from the SurviveTheDeepEnd.com PEAR channel at http://pear.survivethedeepend.com.
Mockery 0.6 features:
- Full Mock Object and Test Stub support
- Lightweight fluent API
- Flexible mocking and stubbing
- Object Interaction Recording
- Natural language syntax and expectation constructs
- Supports generic (untyped) mock objects for rapid prototyping
- Simple partial mocking of real objects
- Both local and global Mock Object call ordering
- Built-in return value queue for repeated method calls
- Support for default expectations
- Support for expectation replacement and stacking
- Fluent API/Law of Demeter mocking
If that sounds complex, it’s not! Mockery can be picked up and used with little study.
Why Mockery?
Mockery’s objective is to simplify Mock Objects in PHP while maintaining significant flexibility and a default level of intuitive behaviour. In Mockery, Mock Objects behave exactly as you write them with liberal interpretations otherwise applied. Mockery was born out of my own need to innovate the use of Mock Objects in PHP and draw away from the original import of aging Mocking approaches from Java. While Java (and almost every other programming language) has been steadily progressing its mock object libraries, and complementing them with new solutions, PHP has a relatively static approach depending on similarly static library components. That result has seen solutions using clunky APIs, poorly described syntax and behaviour, a lack of focus on the practice of using Mock Objects, user confusion, and raised barriers to new programmers trying to learn about Mock Objects. Mockery is one potential solution to these problems. Also, as a dedicated Test-Driven Design user, I really want something that clicks immediately and doesn’t have any gotchas.
Installation
Mockery may be installed from its PEAR channel using:
pear channel-discover pear.survivethedeepend.com
pear install deepend/Mockery
Mockery is written in PHP 5.3 (I know, but all you 5.2 users will get there eventually ). It is released under a New BSD license.
Example
The README offers a good look at some examples, and explains the API in a lot of detail. If you are trying to figure something out, the README undoubtedly has a section for it. Here’s an API example (assuming Mockery namespace used as MK). We’re capturing an interaction where we login into a bookmarking service, check for the existance of a “php” tagged bookmark, add three more bookmarks and then recheck if a “php” tag exists (twice for fun). We’re mocking the service since we don’t actually want to mess with a real account! Following the description closely…
[geshi lang=php]$service = \MK::mock(‘MyService’);
$service->shouldReceive(‘login’)->with(‘user’, ‘pass’)->once()->andReturn(true);
$service->shouldReceive(‘hasBookmarksTagged’)->with(‘php’)->once()->andReturn(false);
$service->shouldReceive(‘addBookmark’)->with(‘/^http:/’, \MK::type(‘string’))->times(3)->andReturn(true);
$service->shouldReceive(‘hasBookmarksTagged’)->with(‘php’)->twice()->andReturn(true);[/geshi]
The example uses some of the basic parts of Mockery to describe some interaction with a mocked web service class (obviously
also stubbing the web service’s responses in terms of booleans). The setup is straightforward, easy to follow, and there’s zero
misinterpretations possible. Our description was likewise simple and uncomplicated. The third line just shows two argument matchers at work, a default regex (intrepreted from any string argument set so long as any eventual string comparison fails and it’s a valid regex) and a Type matcher set to match any valid string.
To put this into some perspective, here’s an equivalent attempt using PHPUnit in a similar order of thought (excerpt from a test).
[geshi lang=php]$service = $this->getMock(‘MyService’);
$service->expects($this->once())->method(‘login’)->with(‘user’, ‘pass’)->will($this->returnValue(true));
$service->expects($this->once())->method(‘hasBookmarksTagged’)->with(‘php’)->will($this->returnValue(false));
$service->expects($this->exactly(3))->method(‘addBookmark’)
->with($this->matchesRegularExpression(‘/^http:/’), $this->isType(‘string’))
->will($this->returnValue(true));
$service->expects($this->exactly(2))->method(‘hasBookmarksTagged’)->with(‘php’)->will($this->returnValue(true));[/geshi]
Besides the differences in API, there are others. If MyService is just intended as a fake unimplemented object (the class doesn’t exist), Mockery carries on and just uses a generic Mock instance without error. PHPUnit will throw an exception, however, stating that login() is not a valid method. If we assume the class is real, but missing some methods, the same thing happens and PHPUnit complains about missing methods. Eventually, you’ll get the idea to implement the dependent class… If we add all the relevant methods (say, we mock an interface with all methods declared), PHPUnit STILL fails. This time complaining that hasBookmarksTagged() was expected only once. This occurs because PHPUnit has no capacity for stacking later expectations, and so, it ignores the second (and any later) ones. We can fix that by merging both into a single expectation using:
[geshi lang=php]$service = $this->getMock(‘MyService’);
$service->expects($this->once())->method(‘login’)->with(‘user’, ‘pass’)->will($this->returnValue(true));
$service->expects($this->exactly(3))->method(‘hasBookmarksTagged’)->with(‘php’)
->will($this->onConsecutiveCalls(false, true, true));
$service->expects($this->exactly(3))->method(‘addBookmark’)
->with($this->matchesRegularExpression(‘/^http:/’), $this->isType(‘string’))
->will($this->returnValue(true));[/geshi]
Using OnConsecutiveCalls() to create a return value queue, and merging the two stacked expectations, allows the PHPUnit variant to pass. Unlike Mockery, if there were ten hasBookmarksTagged() calls, you would need to add all ten return values (Mockery let’s you set the last return value to act infinitely). The merging simply demonstrates that complex class interactions across classes will fall victim to the need to constantly merge expectations until they are unreadable and explain little.
While your mileage may vary, Mockery just doesn’t need reworking, deep thought or extra work. Just state what you want your Mock Object to do in plain unconfused English according to your natural thought order! If nothing else, it helps make the expected interaction obvious which makes your tests more readable and explicit.
Feedback
Any issues can be reported via our Github hosted issue tracker. If you wish to discuss Mockery in more detail, you’re welcome to join the mailing list at http://groups.google.com/group/phpmockery.
reference : http://blog.astrumfutura.com/2010/05/mockery-0-6-released-php-mock-object-framework/
Mockery: From Mock Objects to Test Spies
With next week seeing the formal release of Mockery 0.6 which is currently fermenting on Github at http://github.com/padraic/mockery, I’m already looking forward to next piece of the puzzle arriving with 0.7. Mockery is an opportunity to being something new and fresh to the PHP mock objects environment beyond a far neater flexible API.
If you follow the test double debate in other languages there are two popular concepts making their presence felt. The first is that the over-specified definitions of test doubles (we have dummy objects, test stubs, mock objects, test spies and fake objects) do more harm than good since in reality we never really distinguish (nor care to) between most of them. In most cases we just sort of wing it, using our own concepts and intent to create test doubles which do what we want with little thought as to the kind of test double we’re creating. In the end, the definitions all merge together into a spectrum of possible behaviours we add as and if needed.
The second is that we’re seeing a lot more attention over whether Mock Objects are the best way to do things. Nobody doubts they have the right idea with Mock Objects, but the upfront setting of expectations may come across as unintuitive. A typical test begins with exercising code, and thereafter we typically make assertions on the behaviour (whether it be a resulting state change or an object interaction). Mock Objects reverse that – we expect first, and then we exercise the code.
With the future (before end of June) 0.7 release, Mockery will offer an alternative approach to the traditional Expect-Exercise-Verify cycle called the Test Spy. 0.6 already offers a measure of that capability through its ability to record interactions, though recording is completely automated and geared primarily towards comparing two sets of source code which should behave identically (e.g. during refactoring). The new Test Spy implementation will be API driven, using a similar form to Mockery’s existing Mock Object approach.
Why Test Spies?
Using Test Spies returns to the test based approach of exercising code first, and then making assertions. There’s a reason why this cyclical approach is used in unit testing. It’s easy to understand and makes sense from the start. Applying it to what we do with Mock Objects can make using Test Doubles in general easier to learn and teach. It may also remove barriers to entry for those who simply never understood Mock Objects or loathed their expectation setup. Test Spies also operate on a selective basis – where Mock Objects require upfront expectations to define how they will behave, Test Spies just do what you need them to and then allow selective assertions afterwards (i.e. you only need to test what you want to test).
The difference, once you see the code, is very subtle. Not unusually for testing practices, subtle differences in approach rely on the YMMV yardstick. Some people prefer the upfront expectation setting, others find the after-use assertion approach easier to understand or as more applicable to their thinking.
By supporting both approaches as equal citizens, Mockery once again lets go of the proverbial rope around your neck tied there by Java traditions. You’ll be free to go with whatever approach you find yourself preferring. Better, they can both co-exist in relative peace since they are drawn from the same framework and both share nearly all of the exact same API elements, with the exact same meaning. Whether you prefer Mock Objects or Test Spies (both equally are capable of being used as Test Stubs), they are both equally understandable by anyone using Mockery.
As a means of showing the differences, here are two test cases. The first is written using the Mock Object terminology, the second using the Test Spy terminology – each actually achieves the exact same goal.
[geshi lang=php]use \Mockery as M;
class StarshipTest extends PHPUnit_Framework_TestCase
{
public function testEngagingWarpDrive()
{
$engineering = M::mock(‘Engineering’);
$engineering->shouldReceive(‘prepForWarpFactor’)->with(8)->once()->andReturn(true);
$engineering->shouldReceive(‘engage’)->once();
$starship = new Starship($engineering);
$starship->accelerateToWarp(8);
}
}[/geshi]
Or, using a Test Spy approach.
[geshi lang=php]use \Mockery as M;
class StarshipTest extends PHPUnit_Framework_TestCase
{
public function testEngagingWarpDrive()
{
$engineering = M::mock(‘Engineering’);
$engineering->whenReceives(‘prepForWarpFactor’)->thenReturn(true);
$starship = new Starship($engineering);
$starship->accelerateToWarp(8);
$engineering->assertReceived(‘prepForWarpFactor’)->with(8)->once();
$engineering->assertReceived(‘engage’)->once();
}
}[/geshi]
To demonstrate the selective assertion approach, what if we just didn’t care about whether or not the engage() method was used? In that case, we could just drop it from the assertions altogether – never mentioning it in the test at all. In the Mock Object approach, we cannot do this – mocking means we must set all methods expected (otherwise the methods would not exist on the mock). We could even drop the assertion on prepForWarpFactor, although we still need to retain the stubbing of its return value (since it’s needed).
Supporting Test Spies and Mock Objects also has the other obvious benefit that you can switch modes effortlessly. There will always be cases where expectation setting is preferable over assertions and vice versa. Both have their uses even if you heavily prefer any one over the other.
Watch for the Mockery 0.6 release next week! I’ll follow through with Test Spies in 0.7 once I get the final API down (working on making it even shorter than our Mock Object API can achieve).
reference : http://blog.astrumfutura.com/2010/05/mockery-from-mock-objects-to-test-spies/
If you follow the test double debate in other languages there are two popular concepts making their presence felt. The first is that the over-specified definitions of test doubles (we have dummy objects, test stubs, mock objects, test spies and fake objects) do more harm than good since in reality we never really distinguish (nor care to) between most of them. In most cases we just sort of wing it, using our own concepts and intent to create test doubles which do what we want with little thought as to the kind of test double we’re creating. In the end, the definitions all merge together into a spectrum of possible behaviours we add as and if needed.
The second is that we’re seeing a lot more attention over whether Mock Objects are the best way to do things. Nobody doubts they have the right idea with Mock Objects, but the upfront setting of expectations may come across as unintuitive. A typical test begins with exercising code, and thereafter we typically make assertions on the behaviour (whether it be a resulting state change or an object interaction). Mock Objects reverse that – we expect first, and then we exercise the code.
With the future (before end of June) 0.7 release, Mockery will offer an alternative approach to the traditional Expect-Exercise-Verify cycle called the Test Spy. 0.6 already offers a measure of that capability through its ability to record interactions, though recording is completely automated and geared primarily towards comparing two sets of source code which should behave identically (e.g. during refactoring). The new Test Spy implementation will be API driven, using a similar form to Mockery’s existing Mock Object approach.
Why Test Spies?
Using Test Spies returns to the test based approach of exercising code first, and then making assertions. There’s a reason why this cyclical approach is used in unit testing. It’s easy to understand and makes sense from the start. Applying it to what we do with Mock Objects can make using Test Doubles in general easier to learn and teach. It may also remove barriers to entry for those who simply never understood Mock Objects or loathed their expectation setup. Test Spies also operate on a selective basis – where Mock Objects require upfront expectations to define how they will behave, Test Spies just do what you need them to and then allow selective assertions afterwards (i.e. you only need to test what you want to test).
The difference, once you see the code, is very subtle. Not unusually for testing practices, subtle differences in approach rely on the YMMV yardstick. Some people prefer the upfront expectation setting, others find the after-use assertion approach easier to understand or as more applicable to their thinking.
By supporting both approaches as equal citizens, Mockery once again lets go of the proverbial rope around your neck tied there by Java traditions. You’ll be free to go with whatever approach you find yourself preferring. Better, they can both co-exist in relative peace since they are drawn from the same framework and both share nearly all of the exact same API elements, with the exact same meaning. Whether you prefer Mock Objects or Test Spies (both equally are capable of being used as Test Stubs), they are both equally understandable by anyone using Mockery.
As a means of showing the differences, here are two test cases. The first is written using the Mock Object terminology, the second using the Test Spy terminology – each actually achieves the exact same goal.
[geshi lang=php]use \Mockery as M;
class StarshipTest extends PHPUnit_Framework_TestCase
{
public function testEngagingWarpDrive()
{
$engineering = M::mock(‘Engineering’);
$engineering->shouldReceive(‘prepForWarpFactor’)->with(8)->once()->andReturn(true);
$engineering->shouldReceive(‘engage’)->once();
$starship = new Starship($engineering);
$starship->accelerateToWarp(8);
}
}[/geshi]
Or, using a Test Spy approach.
[geshi lang=php]use \Mockery as M;
class StarshipTest extends PHPUnit_Framework_TestCase
{
public function testEngagingWarpDrive()
{
$engineering = M::mock(‘Engineering’);
$engineering->whenReceives(‘prepForWarpFactor’)->thenReturn(true);
$starship = new Starship($engineering);
$starship->accelerateToWarp(8);
$engineering->assertReceived(‘prepForWarpFactor’)->with(8)->once();
$engineering->assertReceived(‘engage’)->once();
}
}[/geshi]
To demonstrate the selective assertion approach, what if we just didn’t care about whether or not the engage() method was used? In that case, we could just drop it from the assertions altogether – never mentioning it in the test at all. In the Mock Object approach, we cannot do this – mocking means we must set all methods expected (otherwise the methods would not exist on the mock). We could even drop the assertion on prepForWarpFactor, although we still need to retain the stubbing of its return value (since it’s needed).
Supporting Test Spies and Mock Objects also has the other obvious benefit that you can switch modes effortlessly. There will always be cases where expectation setting is preferable over assertions and vice versa. Both have their uses even if you heavily prefer any one over the other.
Watch for the Mockery 0.6 release next week! I’ll follow through with Test Spies in 0.7 once I get the final API down (working on making it even shorter than our Mock Object API can achieve).
reference : http://blog.astrumfutura.com/2010/05/mockery-from-mock-objects-to-test-spies/
The Mockery: An Independent Mock Object and Stub Framework for PHP5
Every testing framework supports Stubs and Mock Objects, well…most of them. No wait, only one really does! SimpleTest. Yes, PHPUnit has a whole chapter on the topic – but let’s just say it’s implementation is more than a little broken.
The side effect of SimpleTest hogging the only true working Mock Object implementation has been an overwhelming de-emphasis in using Mock Objects in PHP. In a world where Unit Testing has given way to Test-Driven Design (TDD), and TDD shows signs of slowly being replaced by, or at a minimum learning from, Behaviour Driven Development (BDD), this lack of Mock Objects just won’t do. PHP needs something concrete in the area.
To that end, and right on the back of my previous MutateMe release, I put my considerable and legendary talents (which exist somewhere between my overweening ego, and my dictionary of GTA IV phone numbers) to work to create Mockery. Unfortunately my conscience forces me to acknowledge the invaluable input from Travis Swicegood (who recently released one of my favourite books on git!) who was deeply involved in the discussions and prototype code around Mockery’s predecessor, PHPMock, and therefore deserves a lot of blam…er…credit .
You can download the initial PEAR package release of 0.1.0alpha from http://dev.phpspec.org/Mockery-0.1.0alpha.tgz or pull from git using the clone URL on the Github.com page at http://github.com/padraic/mockery.
Update #1: Support queries and/or comments and suggestions are also welcome to the Mockery mailing list at http://groups.google.com/group/mockery.
What Is Mockery?
Mockery is an independent Mock Object and Stub framework. It’s not tailored specifically to any one testing framework, rather it’s an entirely separate framework with a discrete API. The idea is that you can use this framework within PHPUnit, or SimpleTest, or anything else really, without being forced to rely on the built-in support (if any) that test framework provides.
Mockery was designed specifically to implement a form of Domain Specific Language (DSL). It makes extensive use of a fluent interface mixed with methods to approximate plain English. A mock object expectation could look like:
[geshi lang=php]$mock->shouldReceive(‘create’)->atLeast()->once()->atMost()->twice()->withAnyArgs()->andReturn(new stdClass);[/geshi]
There’s a lot packed into this single statement, and the natural flow of the DSL (there are no nested methods – only a linear fluent interface) is a major component in allowing your unit tests to remain readable. The API grammer itself is actually tiny – it’s how you mix and match them that makes things interesting and useful.
Being an independent framework, support for Mockery is non-existent in testing frameworks, but that’s not even necessary! Mockery will throw an exception of type Mockery_ExpectationException whenever the Mock Object is used in an unexpected fashion. Most testing frameworks natively report uncaught exceptions as Errors and print the exception’s message to the screen – so the only step needed is to ensure all Mocks are validated at the end of a unit test. Naturally, that would be a nice step to automate within testing frameworks but that’s not essential (maybe someone will hear my cry in the wilderness and adopt us though ).
What are these Mock Objects and Stubs?
Both Mock Objects and Stubs are variants of a Test Double. A Test Double is basically a fake object used to replace another real object in the test. Consider a simple scenario where a Model has a dependency on a Data Mapper, which in turn has a dependency on a database. You have two broad options:
1. Use a real database which means you are really testing the Model, the Data Mapper, and the DBMS as part of an integration test. This creates problems – databases are slow, need to be managed and reset, and why should the Data Mapper or even the database schema even exist yet?
2. Replace the Data Mapper with a fake – a Stub or Mock Object which implements an identical interface, but returns canned predictable responses with a negligible performance hit.
Many people will identify with the first option – there are enough arguments over whether to use a real database when testing to realise it’s a common approach. Fewer will identify with the second, since it has normally (outside of SimpleTest) involved creating special subclasses or mini-stubs.
The purpose of Mockery is not to pass judgement on any practice however – that’s my personal domain . Mockery supports both Mock Objects and Stubs as equal citizens.
The difference between Mocks and Stubs is easier to grasp. A Stub is a static object – it’s created to return canned responses to all method calls. There’s nothing more complicated to learn – it’s that simple.
A Mock Object is a more interactive agent – it’s dynamic since you can literally program it to expect specific methods, with a specific order or number of calls, and return canned data depending on the preceding conditions. Essentially – it allows you to clearly define what interactions you expect the Mock Object to experience during a test. And then validate the Mock to see if your expectations were correct (pass) or incorrect (fail!). Yep – Mock Objectscarry verifiable assertions about what should happen in a test to the Mock.
This side of Mock Objects, asserting its expected behaviour, let’s you design objects in isolation by Mocking their dependencies – even if those dependencies do not yet exist. This has led their charge into mainstream TDD and BDD as a form of API exploration. As you add Mocks, you are basically designing a class’s interface to its dependencies. The concept of Mock Objects as a design tool is now fairly common if a relatively new idea.
Stubbing With Mockery
Mockery support Stubs in a fairly simple fashion. I remember Travis and I had this argument so many times I lost count , so I divorced the idea of a Stub from a Mock to give Stubs a separate and ultra-simple implementation.
As an aside, Mockery offer two primary starting methods:
1. Mockery::mock()
2. mockery()
Both are interchangeable. For simplicity, and because Travis sold me on the idea, I prefer the function method. The function method is also more anonymous so you’re not constantly creating Stubs using a mock() method (to the confusion of whoever reads your tests). To create a Stub, simply call mockery() and provide it with a class name you want to create, and an array of public methods and their return values. Obviously, the class name cannot exist – if the class does already exist you’ll actually receive a Mock Object (but luckily that too will be confined to a Stub so you won’t notice anything different so it still qualifies as a Stub!):
[geshi lang=php]$stub = mockery(‘Foo’, array(‘print’=>’I am Foo!’));[/geshi]
The new object acts just like a class defined as:
[geshi lang=php]class Foo {
public function print() {
return ‘I am Foo!’;
}
}[/geshi]
Either way, the new object will have one thing for certain – it will be of type Foo, sufficient to pass any class hinting you use in your source code. You can set the configuration method array to return any scalar value or object you want, including other Stubs or even Mock Objects if you’re really feeling fiendishly clever.
With the Stub created, you can proceed to pass it into other objects expecting the interface and return values you configured for that test.
Mock Objects with Mockery
Since Mock Objects are more interactive, they offer a broader API. Like Stubs, they always inherit the class type of the class being mocked, and you can also set return values. Unlike Stubs, you can also set expectations!
So one day, this guy who looks like a Klingon, walks into a web development shop. Sounds like a bad joke, eh? . He wants us to design a Ship Control System but gets nervous when asked about Weapons, Propulsion and Power. Left without a clue about these additional system, he hands over some interface requirements to stick to, and we start with one preliminary test (applying TDD).
[geshi lang=php]class BirdOfPreyTest extends PHPUnit_Framework_TestCase {
public function testWarpFactor8() {
$power = mockery(‘KlingonPower’);
$ship = new KlingonBOP($power);
// set Mock Object expectations
$power->shouldReceive(‘checkForWarp’)->once()->with(8)->andReturn(true);
$power->shouldReceive(‘deduct’)->with(80)->once();
// perform action required
$success = $ship->gotoWarp(8);
// add any necessary assertions?
$this->assertTrue($success);
// verify mock expectations
mockery_verify();
}
}[/geshi]
Since the class KlingonPower doesn’t really exist, we use a Mock Object to figure out how interactions should occur. From those interactions, as the example suggests, it’s a simple matter to actually go an implement the real thing! But since this test focuses on the Bird Of Prey control system, no need to run off yet. We don’t have full specs for a Power system, so we continue using Mocks to explore what its API could be.
Let’s implement the KlingonBOP class to make this test pass:
[geshi lang=php]class KlingonBOP {
protected $power = null;
public function __construct(KlingonPower $power) {
$this->power = $power;
}
public function gotoWarp($factor) {
if ($this->power->checkForWarp($factor)) {
$this->power->deduct($factor * 10);
return true;
}
return false;
}
}[/geshi]
As you can see, using the Mock Object guided us more clearly towards the API of a possible Power system class without requiring we actually implement it. A Stub would also have fit, but would not have provided the API behaviour and expectations we used when implementing the KlingonBOP class.
As for feedback on failures, here some example output from PHPUnit as an example. Reporting details should be improved in future iterations.
PHPUnit 3.3.14 by Sebastian Bergmann.
.E
Time: 0 seconds
There was 1 error:
1) testAddWithFailingMock(AdditionTest)
Mockery_ExpectationException: method get() called incorrect number of times;
expected call 2 times but received 1
This is a really simple example, but hopefully it offers a small taste for the usefulness of both Mock Objects and Stubs.
The Mockery API
Here’s the run down of the current starting points to create a Stub or Mock Object:
mockery('Foo');
Create a new Mock Object with the class name and class type of ‘Foo’.
mockery('Foo', array('set'=>null, 'get'=>foo'));
Create a new Stub with the class name and type of ‘Foo’ defining two public methods and their return values.
mockery('Existing_Class');
Create a new Mock Object with a unique class name but a class type of ‘Existing_Class’. The unique class name is unimportant, but used to generate a Mock which is a subclass of any existing Class, Abstract Class or Interface.
mockery('Existing_Class', 'Custom_Name');
Create a new Mock Object with a class name of ‘Custom_Name’ but a class type of ‘Existing_Class’.
mockery('Existing_Class', array('set'=>null, 'get'=>foo'));
Create a new Stub with a unique class name but class type of ‘Existing_Class’ which effectively acts as a Stub (internally this is a variation on a Mock Object but that detail isn’t that important).
Additional tweaks and mixes of options will follow in the next release shortly.
mockery_verify()
Verify all currently unverified Mock Objects – this also exists as a separate method on every Mock Object for more granularity if needed.
The Mockery Mock Object Expectations API
Every Mock Object expectation starts with the shouldReceive() method. This is also the only non-namespaced method added to all objects, and is therefore a reserved method name. Other methods added dynamically to Mock Objects (or Stubs) are prefixed with “mockery_” to minimise the contamination of the object space with methods you might collide with one day.
A shouldReceive() call returns an instance of Mockery_Expectations which accepts expectations for the given method via a fluent interface, i.e. sequential method calls. These methods include:
never()
Expect the method to never be called. Same as times(0).
zeroOrMoreTimes()
Expect the method to be called zero or more times.
once()
Expect the method to be called exactly once. Same as times(1).
twice()
Expect the method to be called exactly twice. Same as times(2).
times(x)
Expect the method to be called x times.
atLeast()
Set a minimum of times to expect the method to be called by appending one of once(), twice(), or times().
atMost()
Set a maximum of times to expect the method to be called by appending one of once(), twice(), or times().
with(x[, y...])
Expect the list of arguments to be passed to the method.
withAnyArgs()
Expect any arguments including no arguments to be passed to the method.
withNoArgs()
Expect no arguments to be passed to the method.
withArgsMatching(x[, y...])
Expect arguments which, when cast to String, match the given list of Regular Expressions.
andReturn(x[, y...])
Set a return value to be returned from the method call. Multiple parameters set an ordered sequence of returns. In both cases, the last listed value is returned indefinitely to all subsequent calls once any preceeding listed values are used.
andThrow(exception[, message])
Set an Exception class to throw including an optional message.
ordered()
Set an expectation method to be called in a specific order. Each use of ordered() on a Mock Object determines the order, but any method expectations omitting this call remain free to be called at any time.
Conclusion
This is an initial alpha release, so while its hopefully sufficiently feature complete to be useful, its main objective is to illicit feedback! If you want new features, API changes, fixes, or have any ideas or comments whatsoever – please post a comment. You can also fork the git repository on Github.com if you want to make fixes so I can pull them back into my own repo for later distribution in a stable release.
reference : http://blog.astrumfutura.com/2009/03/the-mockery-an-independent-mock-object-and-stub-framework-for-php5/
The side effect of SimpleTest hogging the only true working Mock Object implementation has been an overwhelming de-emphasis in using Mock Objects in PHP. In a world where Unit Testing has given way to Test-Driven Design (TDD), and TDD shows signs of slowly being replaced by, or at a minimum learning from, Behaviour Driven Development (BDD), this lack of Mock Objects just won’t do. PHP needs something concrete in the area.
To that end, and right on the back of my previous MutateMe release, I put my considerable and legendary talents (which exist somewhere between my overweening ego, and my dictionary of GTA IV phone numbers) to work to create Mockery. Unfortunately my conscience forces me to acknowledge the invaluable input from Travis Swicegood (who recently released one of my favourite books on git!) who was deeply involved in the discussions and prototype code around Mockery’s predecessor, PHPMock, and therefore deserves a lot of blam…er…credit .
You can download the initial PEAR package release of 0.1.0alpha from http://dev.phpspec.org/Mockery-0.1.0alpha.tgz or pull from git using the clone URL on the Github.com page at http://github.com/padraic/mockery.
Update #1: Support queries and/or comments and suggestions are also welcome to the Mockery mailing list at http://groups.google.com/group/mockery.
What Is Mockery?
Mockery is an independent Mock Object and Stub framework. It’s not tailored specifically to any one testing framework, rather it’s an entirely separate framework with a discrete API. The idea is that you can use this framework within PHPUnit, or SimpleTest, or anything else really, without being forced to rely on the built-in support (if any) that test framework provides.
Mockery was designed specifically to implement a form of Domain Specific Language (DSL). It makes extensive use of a fluent interface mixed with methods to approximate plain English. A mock object expectation could look like:
[geshi lang=php]$mock->shouldReceive(‘create’)->atLeast()->once()->atMost()->twice()->withAnyArgs()->andReturn(new stdClass);[/geshi]
There’s a lot packed into this single statement, and the natural flow of the DSL (there are no nested methods – only a linear fluent interface) is a major component in allowing your unit tests to remain readable. The API grammer itself is actually tiny – it’s how you mix and match them that makes things interesting and useful.
Being an independent framework, support for Mockery is non-existent in testing frameworks, but that’s not even necessary! Mockery will throw an exception of type Mockery_ExpectationException whenever the Mock Object is used in an unexpected fashion. Most testing frameworks natively report uncaught exceptions as Errors and print the exception’s message to the screen – so the only step needed is to ensure all Mocks are validated at the end of a unit test. Naturally, that would be a nice step to automate within testing frameworks but that’s not essential (maybe someone will hear my cry in the wilderness and adopt us though ).
What are these Mock Objects and Stubs?
Both Mock Objects and Stubs are variants of a Test Double. A Test Double is basically a fake object used to replace another real object in the test. Consider a simple scenario where a Model has a dependency on a Data Mapper, which in turn has a dependency on a database. You have two broad options:
1. Use a real database which means you are really testing the Model, the Data Mapper, and the DBMS as part of an integration test. This creates problems – databases are slow, need to be managed and reset, and why should the Data Mapper or even the database schema even exist yet?
2. Replace the Data Mapper with a fake – a Stub or Mock Object which implements an identical interface, but returns canned predictable responses with a negligible performance hit.
Many people will identify with the first option – there are enough arguments over whether to use a real database when testing to realise it’s a common approach. Fewer will identify with the second, since it has normally (outside of SimpleTest) involved creating special subclasses or mini-stubs.
The purpose of Mockery is not to pass judgement on any practice however – that’s my personal domain . Mockery supports both Mock Objects and Stubs as equal citizens.
The difference between Mocks and Stubs is easier to grasp. A Stub is a static object – it’s created to return canned responses to all method calls. There’s nothing more complicated to learn – it’s that simple.
A Mock Object is a more interactive agent – it’s dynamic since you can literally program it to expect specific methods, with a specific order or number of calls, and return canned data depending on the preceding conditions. Essentially – it allows you to clearly define what interactions you expect the Mock Object to experience during a test. And then validate the Mock to see if your expectations were correct (pass) or incorrect (fail!). Yep – Mock Objectscarry verifiable assertions about what should happen in a test to the Mock.
This side of Mock Objects, asserting its expected behaviour, let’s you design objects in isolation by Mocking their dependencies – even if those dependencies do not yet exist. This has led their charge into mainstream TDD and BDD as a form of API exploration. As you add Mocks, you are basically designing a class’s interface to its dependencies. The concept of Mock Objects as a design tool is now fairly common if a relatively new idea.
Stubbing With Mockery
Mockery support Stubs in a fairly simple fashion. I remember Travis and I had this argument so many times I lost count , so I divorced the idea of a Stub from a Mock to give Stubs a separate and ultra-simple implementation.
As an aside, Mockery offer two primary starting methods:
1. Mockery::mock()
2. mockery()
Both are interchangeable. For simplicity, and because Travis sold me on the idea, I prefer the function method. The function method is also more anonymous so you’re not constantly creating Stubs using a mock() method (to the confusion of whoever reads your tests). To create a Stub, simply call mockery() and provide it with a class name you want to create, and an array of public methods and their return values. Obviously, the class name cannot exist – if the class does already exist you’ll actually receive a Mock Object (but luckily that too will be confined to a Stub so you won’t notice anything different so it still qualifies as a Stub!):
[geshi lang=php]$stub = mockery(‘Foo’, array(‘print’=>’I am Foo!’));[/geshi]
The new object acts just like a class defined as:
[geshi lang=php]class Foo {
public function print() {
return ‘I am Foo!’;
}
}[/geshi]
Either way, the new object will have one thing for certain – it will be of type Foo, sufficient to pass any class hinting you use in your source code. You can set the configuration method array to return any scalar value or object you want, including other Stubs or even Mock Objects if you’re really feeling fiendishly clever.
With the Stub created, you can proceed to pass it into other objects expecting the interface and return values you configured for that test.
Mock Objects with Mockery
Since Mock Objects are more interactive, they offer a broader API. Like Stubs, they always inherit the class type of the class being mocked, and you can also set return values. Unlike Stubs, you can also set expectations!
So one day, this guy who looks like a Klingon, walks into a web development shop. Sounds like a bad joke, eh? . He wants us to design a Ship Control System but gets nervous when asked about Weapons, Propulsion and Power. Left without a clue about these additional system, he hands over some interface requirements to stick to, and we start with one preliminary test (applying TDD).
[geshi lang=php]class BirdOfPreyTest extends PHPUnit_Framework_TestCase {
public function testWarpFactor8() {
$power = mockery(‘KlingonPower’);
$ship = new KlingonBOP($power);
// set Mock Object expectations
$power->shouldReceive(‘checkForWarp’)->once()->with(8)->andReturn(true);
$power->shouldReceive(‘deduct’)->with(80)->once();
// perform action required
$success = $ship->gotoWarp(8);
// add any necessary assertions?
$this->assertTrue($success);
// verify mock expectations
mockery_verify();
}
}[/geshi]
Since the class KlingonPower doesn’t really exist, we use a Mock Object to figure out how interactions should occur. From those interactions, as the example suggests, it’s a simple matter to actually go an implement the real thing! But since this test focuses on the Bird Of Prey control system, no need to run off yet. We don’t have full specs for a Power system, so we continue using Mocks to explore what its API could be.
Let’s implement the KlingonBOP class to make this test pass:
[geshi lang=php]class KlingonBOP {
protected $power = null;
public function __construct(KlingonPower $power) {
$this->power = $power;
}
public function gotoWarp($factor) {
if ($this->power->checkForWarp($factor)) {
$this->power->deduct($factor * 10);
return true;
}
return false;
}
}[/geshi]
As you can see, using the Mock Object guided us more clearly towards the API of a possible Power system class without requiring we actually implement it. A Stub would also have fit, but would not have provided the API behaviour and expectations we used when implementing the KlingonBOP class.
As for feedback on failures, here some example output from PHPUnit as an example. Reporting details should be improved in future iterations.
PHPUnit 3.3.14 by Sebastian Bergmann.
.E
Time: 0 seconds
There was 1 error:
1) testAddWithFailingMock(AdditionTest)
Mockery_ExpectationException: method get() called incorrect number of times;
expected call 2 times but received 1
This is a really simple example, but hopefully it offers a small taste for the usefulness of both Mock Objects and Stubs.
The Mockery API
Here’s the run down of the current starting points to create a Stub or Mock Object:
mockery('Foo');
Create a new Mock Object with the class name and class type of ‘Foo’.
mockery('Foo', array('set'=>null, 'get'=>foo'));
Create a new Stub with the class name and type of ‘Foo’ defining two public methods and their return values.
mockery('Existing_Class');
Create a new Mock Object with a unique class name but a class type of ‘Existing_Class’. The unique class name is unimportant, but used to generate a Mock which is a subclass of any existing Class, Abstract Class or Interface.
mockery('Existing_Class', 'Custom_Name');
Create a new Mock Object with a class name of ‘Custom_Name’ but a class type of ‘Existing_Class’.
mockery('Existing_Class', array('set'=>null, 'get'=>foo'));
Create a new Stub with a unique class name but class type of ‘Existing_Class’ which effectively acts as a Stub (internally this is a variation on a Mock Object but that detail isn’t that important).
Additional tweaks and mixes of options will follow in the next release shortly.
mockery_verify()
Verify all currently unverified Mock Objects – this also exists as a separate method on every Mock Object for more granularity if needed.
The Mockery Mock Object Expectations API
Every Mock Object expectation starts with the shouldReceive() method. This is also the only non-namespaced method added to all objects, and is therefore a reserved method name. Other methods added dynamically to Mock Objects (or Stubs) are prefixed with “mockery_” to minimise the contamination of the object space with methods you might collide with one day.
A shouldReceive() call returns an instance of Mockery_Expectations which accepts expectations for the given method via a fluent interface, i.e. sequential method calls. These methods include:
never()
Expect the method to never be called. Same as times(0).
zeroOrMoreTimes()
Expect the method to be called zero or more times.
once()
Expect the method to be called exactly once. Same as times(1).
twice()
Expect the method to be called exactly twice. Same as times(2).
times(x)
Expect the method to be called x times.
atLeast()
Set a minimum of times to expect the method to be called by appending one of once(), twice(), or times().
atMost()
Set a maximum of times to expect the method to be called by appending one of once(), twice(), or times().
with(x[, y...])
Expect the list of arguments to be passed to the method.
withAnyArgs()
Expect any arguments including no arguments to be passed to the method.
withNoArgs()
Expect no arguments to be passed to the method.
withArgsMatching(x[, y...])
Expect arguments which, when cast to String, match the given list of Regular Expressions.
andReturn(x[, y...])
Set a return value to be returned from the method call. Multiple parameters set an ordered sequence of returns. In both cases, the last listed value is returned indefinitely to all subsequent calls once any preceeding listed values are used.
andThrow(exception[, message])
Set an Exception class to throw including an optional message.
ordered()
Set an expectation method to be called in a specific order. Each use of ordered() on a Mock Object determines the order, but any method expectations omitting this call remain free to be called at any time.
Conclusion
This is an initial alpha release, so while its hopefully sufficiently feature complete to be useful, its main objective is to illicit feedback! If you want new features, API changes, fixes, or have any ideas or comments whatsoever – please post a comment. You can also fork the git repository on Github.com if you want to make fixes so I can pull them back into my own repo for later distribution in a stable release.
reference : http://blog.astrumfutura.com/2009/03/the-mockery-an-independent-mock-object-and-stub-framework-for-php5/
The Case For Dependency Injection – Part 2
The Recap
In Part 1 of this series, we briefly passed over the concept of Dependency Injection, identifying several injection strategies as below:
1. Constructor Injection
2. Setter Injection
3. Factory Design Pattern
These three patterns have been the mainstay in managing dependencies in PHP source code ever since PHP was capable of handling object oriented programming. However, these strategies can accumulate problems:
1. They require manual management of dependencies when creating new objects.
2. They require users to understand the internal workings of dependencies.
3. They clutter APIs with undocumented methods.
4. They add complexity to tests since manual injections must be performed.
5. They increase the cost of change (manual editing is needed for API changes)
6. They promote static methods in PHP (easier than creating specific objects).
This is not to say, don’t use them! In most circumstances, application of the well known strategies is not only possible but advisable. There is little benefit adding the complexity inherent in Inversion Of Control to simple scenarios.
Inversion Of Control applies to the complex, not the simple.
In isolation, none of these strategies are anything but innocent. But their combined complexity increases as your application grows and networks of classes acumulate. That’s why simple examples of Dependency Injection are doomed to failure – the problems have simple solutions. What we need is something to illustrate that Dependency Injection and Inversion Of Control are applicable to something more concrete, like a fully formed Klingon Bird Of Prey with all the bells and whistles!
[geshi lang=php]class Ship_Klingon_BirdOfPrey {
// arrays indicate multiple object instances are required
protected $warpCore = null;
protected $disruptorBanks = array();
protected $warpEngine = null;
protected $shields = array();
protected $crew = null;
protected $shipsLog = null;
protected $computer = null;
protected $sensors = array();
// …
}[/geshi]
Are you getting the picture yet? Consider any application based on a complicated process. You may have dozens of objects working in concert towards a single goal. Kapla!
To create the client object, a Bird Of Prey, you need to inject every service object it requires since they are needed. In a simple use case, however, the user only wants a damn ship! They don’t care about the components unless they have a need to customise some internal operation. In this scenario, the Factory option might work. Using the Factory, we need to cover off on the testing piping using static means. We could just use any available setters or constructor parameters – but then our tests are going to be huge whenever a new Ship is needed.
But let’s dig deeper! How will we use the Ships Log? Every component will need to report it’s status there – so the Log is a service to the Ship, and to every other sub-system. Let’s double our Factory method length. Now, what if the computer needs to liase with the Sensors, acquire a Target via the Computer, and order the Disruptor Banks to fire? So the Sensors, Log, Disruptor Banks and possible Crew complement become needed by the Computer. Let’s double…nay…quadruple everything.
Next we decide to give the Computer a database, along with the Log, the Ship and maybe the Crew. Or we realise half this stuff are Models anyway, so give them all databases to play with!
Excuse me while I sit in a corner and cry…I only wanted a bloody ship! Why are making me do all this?
The Service Locator Pattern
Complex problems can still have simple solutions, and the Service Locator has long superceded the Factory when the going gets a bit tougher. Manually handling complex dependencies is insane (on all levels), so a little configuration can be handy.
A simple Service Locator is used like a map. If an object needs a specific service object, it refers to the Locator to retrieve a copy. You can embellish the system in any number of ways using keywords, tagging, URLs, and even utilise concrete Factories as needed, but the simplest Service Locator is a plain old array (which is also the simplest Registry):
[geshi lang=php]$locator = array(
‘log’ => new Ship_Log,
‘warpCore’ => new Ship_WarpCore,
‘computer’ => new Ship_Computer,
‘warpEngine’ => new Ship_WarpEngine,
// …
);[/geshi]
If you pass this locator to the Bird Of Prey, and let the BOP pass it to all other service objects it retrieves from the Locator array, then you can cut out the complex web of dependencies from manual management and let them all refer to the Locator instead. You can even adapt the Locator in tests to return Mock Objects. Aside from object lookup, you can also integrate configuration so the located objects can be constructed correctly.
So where are the negatives? Well, now everything needs to know about this super Service Locator, since otherwise objects couldn’t find their dependencies. It also ignores the order of creation – some objects need to be created before others or the more circular dependencies will fail to be available. If we try to create the Computer, but not the Log, then we can’t give the Computer a Log and the locator will fail. This would necessitate…manual intervention. We’d need to manually track and switch around code across numerous classes to ensure the order of creation is executed correctly. This is far from ideal, so while a Service Locator is a highly useful tool in the toolbox, orchestrating the dependency web needs something more.
The Next Obvious Evolution
As we gradually evolve from simple injection, the Service Locator was revealed as a capable, lightweight, flexible solution. It’s primary problem was dependency resolution. Rather than scatter this across all those classes, why not simply centralise them in the Service Locator itself? It’s at this point we shift from a Locator, to a simple Dependency Injection Container (ah, finally the Container term ) and leave our poor overburdened objects free of this distraction to focus solely on their roles.
Here’s an ultra simple IOC container:
[geshi lang=php]class DIContainer {
protected $_data = array();
public function set($name, $value) {
$this->data[$name] = $value;
}
public function get($name) {
if (isset($this->data[$name])) {
return $this->data[$name];
}
return $this->call(‘get’.ucfirst($name));
}
protected function getLog() {
$log = new Ship_Log($this->get(‘logfile’));
$this->data['log'] = $log;
return $log;
}
protected function getWarpCore() {
$warpCore = new Ship_WarpCore();
$this->data['warpCore'] = $warpCore;
$warpCore->setLog($this->get(‘log’));
}
protected function call($method) {
return $this->{$method}();
}
// …
}[/geshi]
This new Container class is a really simple implementation of a DI Container which assumes all client objects will utilise the exact same service objects. Like a Service Locator, you can use it to grab registered objects. However, it is written to also determine the order of creation of any object requested, then create it, and finally return it.
[geshi lang=php]$container = new DIContainer;
$container->set(‘logfile’, ‘/tmp/shiplog’);
$warpCore = $container->get(‘warpCore’);[/geshi]
A completed version could utilise the simple Strategy Pattern so you could have a single container for specific Model types accepting configuration options for everything the Container needs.
[geshi lang=php]$container = new DIContainer_Ship;
$container->set(‘type’, ‘Klingon BOP’);
$container->set(‘logfile’, ‘/tmp/shiplog’);
$container->set(‘db_type’, ‘mysql’);
$container->set(‘ship_db_table’, ‘ships’);
$container->set(‘capacity’, ’300′);
$ship = $container->get(‘ship’);[/geshi]
Of course, let’s not let this get away free . The obvious flaw is the amount of manual programming it still needs, even though it’s drastically reduced the overall code need by avoiding code duplication and centralising this task. While the dependency management is cool, the wiring is all manual. Adding the element of automation to the new Container concept with a little Reflection and typehinting could go far. Adding cloning might speed up the creation of Containers by allowing minor configuration tweaks. Adding object replacement would allow for Mock/Stub insertion. I’m sure you can think of lots of added elements to make something easier to utilise.
Conclusion
We’ve finally met the simplest kind of IOC possible. In Part 3, we’ll move outside this simple and flawed implementation, and take a look at the forms of IOC frameworks living in the wild whether they be PHP, Python or Ruby. Frameworks should, in theory, make these Containers a lot easier to setup and maintain in a more strucured form that removes the need for customising classes. Instead mixing convention with some configuration, and taking advantage of Reflection, should produce more maintainable and testable options.
reference : http://blog.astrumfutura.com/2009/03/the-case-for-dependency-injection-part-2/
In Part 1 of this series, we briefly passed over the concept of Dependency Injection, identifying several injection strategies as below:
1. Constructor Injection
2. Setter Injection
3. Factory Design Pattern
These three patterns have been the mainstay in managing dependencies in PHP source code ever since PHP was capable of handling object oriented programming. However, these strategies can accumulate problems:
1. They require manual management of dependencies when creating new objects.
2. They require users to understand the internal workings of dependencies.
3. They clutter APIs with undocumented methods.
4. They add complexity to tests since manual injections must be performed.
5. They increase the cost of change (manual editing is needed for API changes)
6. They promote static methods in PHP (easier than creating specific objects).
This is not to say, don’t use them! In most circumstances, application of the well known strategies is not only possible but advisable. There is little benefit adding the complexity inherent in Inversion Of Control to simple scenarios.
Inversion Of Control applies to the complex, not the simple.
In isolation, none of these strategies are anything but innocent. But their combined complexity increases as your application grows and networks of classes acumulate. That’s why simple examples of Dependency Injection are doomed to failure – the problems have simple solutions. What we need is something to illustrate that Dependency Injection and Inversion Of Control are applicable to something more concrete, like a fully formed Klingon Bird Of Prey with all the bells and whistles!
[geshi lang=php]class Ship_Klingon_BirdOfPrey {
// arrays indicate multiple object instances are required
protected $warpCore = null;
protected $disruptorBanks = array();
protected $warpEngine = null;
protected $shields = array();
protected $crew = null;
protected $shipsLog = null;
protected $computer = null;
protected $sensors = array();
// …
}[/geshi]
Are you getting the picture yet? Consider any application based on a complicated process. You may have dozens of objects working in concert towards a single goal. Kapla!
To create the client object, a Bird Of Prey, you need to inject every service object it requires since they are needed. In a simple use case, however, the user only wants a damn ship! They don’t care about the components unless they have a need to customise some internal operation. In this scenario, the Factory option might work. Using the Factory, we need to cover off on the testing piping using static means. We could just use any available setters or constructor parameters – but then our tests are going to be huge whenever a new Ship is needed.
But let’s dig deeper! How will we use the Ships Log? Every component will need to report it’s status there – so the Log is a service to the Ship, and to every other sub-system. Let’s double our Factory method length. Now, what if the computer needs to liase with the Sensors, acquire a Target via the Computer, and order the Disruptor Banks to fire? So the Sensors, Log, Disruptor Banks and possible Crew complement become needed by the Computer. Let’s double…nay…quadruple everything.
Next we decide to give the Computer a database, along with the Log, the Ship and maybe the Crew. Or we realise half this stuff are Models anyway, so give them all databases to play with!
Excuse me while I sit in a corner and cry…I only wanted a bloody ship! Why are making me do all this?
The Service Locator Pattern
Complex problems can still have simple solutions, and the Service Locator has long superceded the Factory when the going gets a bit tougher. Manually handling complex dependencies is insane (on all levels), so a little configuration can be handy.
A simple Service Locator is used like a map. If an object needs a specific service object, it refers to the Locator to retrieve a copy. You can embellish the system in any number of ways using keywords, tagging, URLs, and even utilise concrete Factories as needed, but the simplest Service Locator is a plain old array (which is also the simplest Registry):
[geshi lang=php]$locator = array(
‘log’ => new Ship_Log,
‘warpCore’ => new Ship_WarpCore,
‘computer’ => new Ship_Computer,
‘warpEngine’ => new Ship_WarpEngine,
// …
);[/geshi]
If you pass this locator to the Bird Of Prey, and let the BOP pass it to all other service objects it retrieves from the Locator array, then you can cut out the complex web of dependencies from manual management and let them all refer to the Locator instead. You can even adapt the Locator in tests to return Mock Objects. Aside from object lookup, you can also integrate configuration so the located objects can be constructed correctly.
So where are the negatives? Well, now everything needs to know about this super Service Locator, since otherwise objects couldn’t find their dependencies. It also ignores the order of creation – some objects need to be created before others or the more circular dependencies will fail to be available. If we try to create the Computer, but not the Log, then we can’t give the Computer a Log and the locator will fail. This would necessitate…manual intervention. We’d need to manually track and switch around code across numerous classes to ensure the order of creation is executed correctly. This is far from ideal, so while a Service Locator is a highly useful tool in the toolbox, orchestrating the dependency web needs something more.
The Next Obvious Evolution
As we gradually evolve from simple injection, the Service Locator was revealed as a capable, lightweight, flexible solution. It’s primary problem was dependency resolution. Rather than scatter this across all those classes, why not simply centralise them in the Service Locator itself? It’s at this point we shift from a Locator, to a simple Dependency Injection Container (ah, finally the Container term ) and leave our poor overburdened objects free of this distraction to focus solely on their roles.
Here’s an ultra simple IOC container:
[geshi lang=php]class DIContainer {
protected $_data = array();
public function set($name, $value) {
$this->data[$name] = $value;
}
public function get($name) {
if (isset($this->data[$name])) {
return $this->data[$name];
}
return $this->call(‘get’.ucfirst($name));
}
protected function getLog() {
$log = new Ship_Log($this->get(‘logfile’));
$this->data['log'] = $log;
return $log;
}
protected function getWarpCore() {
$warpCore = new Ship_WarpCore();
$this->data['warpCore'] = $warpCore;
$warpCore->setLog($this->get(‘log’));
}
protected function call($method) {
return $this->{$method}();
}
// …
}[/geshi]
This new Container class is a really simple implementation of a DI Container which assumes all client objects will utilise the exact same service objects. Like a Service Locator, you can use it to grab registered objects. However, it is written to also determine the order of creation of any object requested, then create it, and finally return it.
[geshi lang=php]$container = new DIContainer;
$container->set(‘logfile’, ‘/tmp/shiplog’);
$warpCore = $container->get(‘warpCore’);[/geshi]
A completed version could utilise the simple Strategy Pattern so you could have a single container for specific Model types accepting configuration options for everything the Container needs.
[geshi lang=php]$container = new DIContainer_Ship;
$container->set(‘type’, ‘Klingon BOP’);
$container->set(‘logfile’, ‘/tmp/shiplog’);
$container->set(‘db_type’, ‘mysql’);
$container->set(‘ship_db_table’, ‘ships’);
$container->set(‘capacity’, ’300′);
$ship = $container->get(‘ship’);[/geshi]
Of course, let’s not let this get away free . The obvious flaw is the amount of manual programming it still needs, even though it’s drastically reduced the overall code need by avoiding code duplication and centralising this task. While the dependency management is cool, the wiring is all manual. Adding the element of automation to the new Container concept with a little Reflection and typehinting could go far. Adding cloning might speed up the creation of Containers by allowing minor configuration tweaks. Adding object replacement would allow for Mock/Stub insertion. I’m sure you can think of lots of added elements to make something easier to utilise.
Conclusion
We’ve finally met the simplest kind of IOC possible. In Part 3, we’ll move outside this simple and flawed implementation, and take a look at the forms of IOC frameworks living in the wild whether they be PHP, Python or Ruby. Frameworks should, in theory, make these Containers a lot easier to setup and maintain in a more strucured form that removes the need for customising classes. Instead mixing convention with some configuration, and taking advantage of Reflection, should produce more maintainable and testable options.
reference : http://blog.astrumfutura.com/2009/03/the-case-for-dependency-injection-part-2/
The Case For Dependency Injection – Part 1
It’s been years since I first met the concept of Dependency Injection, and despite the influx of proposals, actual libraries, and spotty writing on the topic, it remains elusive in PHP. Well, with my newfound freedom to bang on my keyboard and commit real time to development and writing, I’m making this provocative and sometimes accusatory entry to perhaps spark some progress.
What is Dependency Injection?
Explaining Dependency Injection is not that hard:
[geshi lang=php]class KlingonBOP {
public $power = null;
public function __construct() {
$this->power = new WarpCore();
}
public function toWarp($factor) {
if($this->power->has($factor*10)) {
return true;
}
return false
}
}[/geshi]
This KlingonBOP class can be thought of as a client which depends on services (other objects) in order to function (the analogy is really to assist understanding the relationships), like the WarpCore object which is a service to the KlingonBOP client.
Now consider how write a unit test for this class. Unit testing works by testing classes in isolation from their dependencies – this rules out any unintended interference from other classes (i.e. a cascading set of failures), and also removes the need to actually develop the service/dependent class right now.
In the code above, we have an obvious problem – in a test, we cannot replace the WarpCore object since it is explicitly instantiated in the constructor. By replace, I mean write the tests using a Mock Object or Stub instead of a real WarpCore instance, something which has predictable constant return values.
Dependency Injection Strategies
Dependency Injection is all about how to inject these service objects into the client objects, making use of them in such a way they can be easily swapped by any other source code (not just tests!). Assuming you’re with me so far, you can identify the two most obvious Dependency Injection strategies:
1. Pass the service to the constructor as a parameter (contructor injection).
2. Pass the service to a class mutator/setter method (setter injection).
Using either of these, we can write a nice isolated unit test such as:
[geshi lang=php]require ‘Mockery/Framework.php’;
class KlingonShipTest extends PHPUnit_Framework_TestCase {
public function testAllowsWarpIfSufficientPowerAvailable() {
$ship = new KlingonBOP(
mockery(‘WarpCore_Stub’, array(‘toWarp’, ‘true’))
);
$this->assertTrue($ship->toWarp(1));
}
}[/geshi]
or
[geshi lang=php]require ‘Mockery/Framework.php’;
class KlingonShipTest extends PHPUnit_Framework_TestCase {
public function testAllowsWarpIfSufficientPowerAvailable() {
$ship = new KlingonBOP();
$ship->setWarpCore(
mockery(‘WarpCore_Stub’, array(‘toWarp’, ‘true’))
);
$this->assertTrue($ship->toWarp(1));
}
}[/geshi]
Now we can edit the class for the constructor injection or setter injection strategies as appropriate…
These two DI options are often called “Manual Dependency Injection” or “Construction By Hand”, a reference to the fact we are manually constructing and handing services to client objects. Every single service object gets the manual treatment, and that’s the norm in most PHP source code. It’s a primary underpinning of the concept of composition in OOP afterall.
So what’s the problem? It’s manual!
Anything manual has two facets. First, you need to know how to do it by hand (RTFM ). Secondly, you better do it right and add more tests. Third, it must be duplicated everywhere so you better not forget how to do it…ever!
Being manual isn’t all bad though, most objects need one, two or at most three service objects. It’s messy in large doses but quite manageable. It’s when things become unmanageable that it becomes interesting because its at that point all those fluffy ideals like unit testing and decoupling are thrown out the window (I prefer to flush mine down the drain, but everyone’s a critic).
The most likely outcome of the manual approach is the duplication of all that object wiring. What happens if the API changes? You need to manually re-edit all those instantiations and API calls across the application(s). When they break BC for the next version? Manually edit…again. The other is requiring in-depth knowledge of every detail including how internal objects are utilised. Besides adding additional onus on people to refer constantly to the manual, or far worse – the source code itself, it ignores the concept that only the outer public API has real value – the rest is just an annoying burden of knowledge weighing us down. I don’t know about other programmers, but I never bother to memorise anything but a library’s basics. Why should I? Programmers are supposed to be supported in their group laziness .
Let’s emphasise everything so far by moving onto Dependency Injection strategy three – the Factory and Abstract Factory design patterns. You didn’t really think I forgot about them, did you? .
Both patterns have simple goals, to centralise the creation logic of objects so they are easier to reuse, and reduce code duplication across your source code where the created objects are needed. Typically they wind up being class methods. Annoying, irksome, untestable, static class methods.
But let’s not go overboard, we can make the Factories into specific classes (they have a separate role afterall!) with public methods instead (PHP is obsessed with those bloody static methods so the trail ends there usually) which instantly makes them amenable to Dependency Injection strategies 1 and 2 (and allows you to mock/stub the factory object in tests). This does wonders, and then you find out about the punchline…
Factories add three layers of complexity, not two, so you now need to double up on Mock Objects and stubs in tests. To utilise Mock Objects in place of the dependent object (created by the Factory class for the dependee), you need a way to force the Factory to send out mocks or stubs in place of creating an actual new object. At this point you start scratching your head, so you throw in a setter which you realise won’t work (Factories don’t remember what they create, they just return the end product immediately), and perhaps toe across the line and apply the Registry pattern to make Factories hold a static memory of any mock/stub you need it to use instead of creating a new one. Sometimes you’ll simply do away with the Factory (basically accepting the cost of its loss in added complexity to the end user!) and fall back on setter/constructor injection.
We’ll assume that the tactic used is the simpler option – stub the Factory class, and set a canned response which is actually another mock/stub of the object being created. Twice the mocks, unless it’s a static method (yes, I am hating static methods way too often in this post ).
If there is such a thing a Singletonitis, Factoryitis is a close relative. A simple Factory is great, but then you realise the Factory isn’t creating one single universal object, it’s dynamically creating variations based on passed parameters, config files, or via multiple public methods for hand coded variations. That’s a lot of surrounding code, and if your original duplication varied on the inputs, a Factory buys you little benefit apart from centralising all that muck in one place where it builds up and grows into complex monolithic code blocks. And how do you even test the Factory anyway? You already tested each object it creates, so you duplicate that to maintain some sanity?
Note: You can test even static factories, once you remember to clean them up in reverse. Technically though, you still can’t mock or stub the buggers without adding test wiring – extraneous methods and properties only used by tests.
This raises a spectre of a problem – if a factory is not easily tested, and we sacrifice it to fall back on more testable injection strategies, we’re lost the benefits of the factory in reducing complexity to the end user and code duplication across the source. Can we take back control?
Dependency Injection: The Inversion Of Control
So we know the basics, inherently, without really calling them Dependency Injection outright, but Dependency Injection is also its own strategy by combining facets of all these strategies into a single comprehensive solution. Something that makes testing, composition, and configured creation easy without all the nasty consequences (well, so it claims – judge for yourself). From now on I’ll refer to this overarching strategy simply as Inversion Of Control (IOC). Often IOC is used interchangeably with DI which can be confusing, so bear in mind DI is IOC plus the original injection strategies I’ve mentioned so far.
IOC makes a few assumptions I’m already pushed around. It needs to make testing easy. It needs to avoid manual coding of dependencies. It also needs to remain ignorant of the dependencies until it’s told what to do. It also assumes all objects used in object creation remain loosely coupled (one of the cardinal sins often used in opposition to DI) and abide to API contracts (code to the interface, not the implementation!). In fact it presumes a common deferred approach – objects expect their dependents to be handed to them, but they never actively seek those dependencies by themselves. A sort of don’t call me, I’ll call you approach on the part of dependents.
The primary member of any IOC strategy is the Injector. You might see DI frameworks referring to the Container more often, but we’ll get around to why its called a Container – in there somewhere is always an Injector. As the name suggests, Injectors exist to inject dependents into dependees. Much as you do manually in the previous DI strategies.
Anyone familiar with objects will realise its role quite easily – the Injector creates all service objects with all of their own dependencies injected (preferably without creating an infinite loop though ) and injects those service objects into the client object being created before returning the client object for use. We’ll explore the concept and approach in another post soon, assess the current state of play in PHP of Dependency Injection, and see where DI can be dragged into actual source code in a useful way.
Until next time…
reference:http://blog.astrumfutura.com/2009/03/the-case-for-dependency-injection-part-1/
What is Dependency Injection?
Explaining Dependency Injection is not that hard:
[geshi lang=php]class KlingonBOP {
public $power = null;
public function __construct() {
$this->power = new WarpCore();
}
public function toWarp($factor) {
if($this->power->has($factor*10)) {
return true;
}
return false
}
}[/geshi]
This KlingonBOP class can be thought of as a client which depends on services (other objects) in order to function (the analogy is really to assist understanding the relationships), like the WarpCore object which is a service to the KlingonBOP client.
Now consider how write a unit test for this class. Unit testing works by testing classes in isolation from their dependencies – this rules out any unintended interference from other classes (i.e. a cascading set of failures), and also removes the need to actually develop the service/dependent class right now.
In the code above, we have an obvious problem – in a test, we cannot replace the WarpCore object since it is explicitly instantiated in the constructor. By replace, I mean write the tests using a Mock Object or Stub instead of a real WarpCore instance, something which has predictable constant return values.
Dependency Injection Strategies
Dependency Injection is all about how to inject these service objects into the client objects, making use of them in such a way they can be easily swapped by any other source code (not just tests!). Assuming you’re with me so far, you can identify the two most obvious Dependency Injection strategies:
1. Pass the service to the constructor as a parameter (contructor injection).
2. Pass the service to a class mutator/setter method (setter injection).
Using either of these, we can write a nice isolated unit test such as:
[geshi lang=php]require ‘Mockery/Framework.php’;
class KlingonShipTest extends PHPUnit_Framework_TestCase {
public function testAllowsWarpIfSufficientPowerAvailable() {
$ship = new KlingonBOP(
mockery(‘WarpCore_Stub’, array(‘toWarp’, ‘true’))
);
$this->assertTrue($ship->toWarp(1));
}
}[/geshi]
or
[geshi lang=php]require ‘Mockery/Framework.php’;
class KlingonShipTest extends PHPUnit_Framework_TestCase {
public function testAllowsWarpIfSufficientPowerAvailable() {
$ship = new KlingonBOP();
$ship->setWarpCore(
mockery(‘WarpCore_Stub’, array(‘toWarp’, ‘true’))
);
$this->assertTrue($ship->toWarp(1));
}
}[/geshi]
Now we can edit the class for the constructor injection or setter injection strategies as appropriate…
These two DI options are often called “Manual Dependency Injection” or “Construction By Hand”, a reference to the fact we are manually constructing and handing services to client objects. Every single service object gets the manual treatment, and that’s the norm in most PHP source code. It’s a primary underpinning of the concept of composition in OOP afterall.
So what’s the problem? It’s manual!
Anything manual has two facets. First, you need to know how to do it by hand (RTFM ). Secondly, you better do it right and add more tests. Third, it must be duplicated everywhere so you better not forget how to do it…ever!
Being manual isn’t all bad though, most objects need one, two or at most three service objects. It’s messy in large doses but quite manageable. It’s when things become unmanageable that it becomes interesting because its at that point all those fluffy ideals like unit testing and decoupling are thrown out the window (I prefer to flush mine down the drain, but everyone’s a critic).
The most likely outcome of the manual approach is the duplication of all that object wiring. What happens if the API changes? You need to manually re-edit all those instantiations and API calls across the application(s). When they break BC for the next version? Manually edit…again. The other is requiring in-depth knowledge of every detail including how internal objects are utilised. Besides adding additional onus on people to refer constantly to the manual, or far worse – the source code itself, it ignores the concept that only the outer public API has real value – the rest is just an annoying burden of knowledge weighing us down. I don’t know about other programmers, but I never bother to memorise anything but a library’s basics. Why should I? Programmers are supposed to be supported in their group laziness .
Let’s emphasise everything so far by moving onto Dependency Injection strategy three – the Factory and Abstract Factory design patterns. You didn’t really think I forgot about them, did you? .
Both patterns have simple goals, to centralise the creation logic of objects so they are easier to reuse, and reduce code duplication across your source code where the created objects are needed. Typically they wind up being class methods. Annoying, irksome, untestable, static class methods.
But let’s not go overboard, we can make the Factories into specific classes (they have a separate role afterall!) with public methods instead (PHP is obsessed with those bloody static methods so the trail ends there usually) which instantly makes them amenable to Dependency Injection strategies 1 and 2 (and allows you to mock/stub the factory object in tests). This does wonders, and then you find out about the punchline…
Factories add three layers of complexity, not two, so you now need to double up on Mock Objects and stubs in tests. To utilise Mock Objects in place of the dependent object (created by the Factory class for the dependee), you need a way to force the Factory to send out mocks or stubs in place of creating an actual new object. At this point you start scratching your head, so you throw in a setter which you realise won’t work (Factories don’t remember what they create, they just return the end product immediately), and perhaps toe across the line and apply the Registry pattern to make Factories hold a static memory of any mock/stub you need it to use instead of creating a new one. Sometimes you’ll simply do away with the Factory (basically accepting the cost of its loss in added complexity to the end user!) and fall back on setter/constructor injection.
We’ll assume that the tactic used is the simpler option – stub the Factory class, and set a canned response which is actually another mock/stub of the object being created. Twice the mocks, unless it’s a static method (yes, I am hating static methods way too often in this post ).
If there is such a thing a Singletonitis, Factoryitis is a close relative. A simple Factory is great, but then you realise the Factory isn’t creating one single universal object, it’s dynamically creating variations based on passed parameters, config files, or via multiple public methods for hand coded variations. That’s a lot of surrounding code, and if your original duplication varied on the inputs, a Factory buys you little benefit apart from centralising all that muck in one place where it builds up and grows into complex monolithic code blocks. And how do you even test the Factory anyway? You already tested each object it creates, so you duplicate that to maintain some sanity?
Note: You can test even static factories, once you remember to clean them up in reverse. Technically though, you still can’t mock or stub the buggers without adding test wiring – extraneous methods and properties only used by tests.
This raises a spectre of a problem – if a factory is not easily tested, and we sacrifice it to fall back on more testable injection strategies, we’re lost the benefits of the factory in reducing complexity to the end user and code duplication across the source. Can we take back control?
Dependency Injection: The Inversion Of Control
So we know the basics, inherently, without really calling them Dependency Injection outright, but Dependency Injection is also its own strategy by combining facets of all these strategies into a single comprehensive solution. Something that makes testing, composition, and configured creation easy without all the nasty consequences (well, so it claims – judge for yourself). From now on I’ll refer to this overarching strategy simply as Inversion Of Control (IOC). Often IOC is used interchangeably with DI which can be confusing, so bear in mind DI is IOC plus the original injection strategies I’ve mentioned so far.
IOC makes a few assumptions I’m already pushed around. It needs to make testing easy. It needs to avoid manual coding of dependencies. It also needs to remain ignorant of the dependencies until it’s told what to do. It also assumes all objects used in object creation remain loosely coupled (one of the cardinal sins often used in opposition to DI) and abide to API contracts (code to the interface, not the implementation!). In fact it presumes a common deferred approach – objects expect their dependents to be handed to them, but they never actively seek those dependencies by themselves. A sort of don’t call me, I’ll call you approach on the part of dependents.
The primary member of any IOC strategy is the Injector. You might see DI frameworks referring to the Container more often, but we’ll get around to why its called a Container – in there somewhere is always an Injector. As the name suggests, Injectors exist to inject dependents into dependees. Much as you do manually in the previous DI strategies.
Anyone familiar with objects will realise its role quite easily – the Injector creates all service objects with all of their own dependencies injected (preferably without creating an infinite loop though ) and injects those service objects into the client object being created before returning the client object for use. We’ll explore the concept and approach in another post soon, assess the current state of play in PHP of Dependency Injection, and see where DI can be dragged into actual source code in a useful way.
Until next time…
reference:http://blog.astrumfutura.com/2009/03/the-case-for-dependency-injection-part-1/
訂閱：
文章 (Atom)
發表文章
