PHP, Zend Framework and Other Crazy Stuff
Posts tagged php
Mockery 0.9.0 Has Landed…Mostly In One Piece!
Feb 6th
The Enterprise ' s saucer section crash landing (Photo credit: Wikipedia)
I’m very happy to announce the release of Mockery 0.9.0.
Mockery is a simple yet flexible PHP mock object framework for use in unit testing with PHPUnit, PHPSpec or any other testing framework. Its core goal is to offer a test double framework with a succint API capable of clearly defining all possible object operations and interactions using a human readable Domain Specific Language (DSL). Designed as a drop in alternative to PHPUnit’s phpunit-mock-objects library, Mockery is easy to integrate with PHPUnit and can operate alongside phpunit-mock-objects without the World ending.
According to the number crunching machines over at VersionEye, Mockery is the 7th most referenced Composer package for PHP with 1,051 packages currently referencing Mockery as a development dependency. That is a great achievement and I appreciate the efforts of everyone who has taken the time to send in issues and pull requests.
Thanks to the efforts of Dave Marshall (@davedevelopment), who has taken point on Mockery for most of 2013, the new release improves stability, performance and compatibility with HHVM. I was going to trawl through the commits to write a summary of changes, but Dave was kind enough to do that for me too so here are the highlights. The new 0.9.0 release is now available on Packagist.org and through the SurviveTheDeepend.org PEAR channel.
Mocking Protected Methods
Contentious point for purists, but Mockery now allows you to mock protected methods, but it’s specifically opt-in. Its main use case will be shorthand for making fake derivatives of abstract classes.
<?php
require "vendor/autoload.php";
abstract class Foo
{
public function bar()
{
$res = $this->doBar();
return $res * 2;
}
abstract protected function doBar();
}
$foo = Mockery::mock("Foo")->makePartial()
->shouldAllowMockingProtectedMethods();
$foo->shouldReceive("doBar")->andReturn(128);
echo $foo->bar(); // 256
Generator Rewrite
The code generation has been completely rewritten, it’s a little cleaner and has more unit tests. This new generator is now wrapped with a caching layer by default. This means that Mockery wont generate a new mock class if it’s already generated a suitable class.
<?php
$fooMock1 = Mockery::mock("Foo"); // generates a mock class deriving from Foo
$fooMock2 = Mockery::mock("Foo"); // re-uses the same mock class
$partialFoo = Mockery::mock("Foo[bar]"); // can't reuse class, so generates new
This brings significant performance boosts on larger suites, particularly with memory consumption. It’s not all that important to some, but I like a fast feedback loop and it will definitely help some people running their suites on travis with xdebug for coverage.
laravel/framework with Mockery 0.8.0 and Zend PHP 5.5.6 Time: 3.9 seconds, Memory: 276.50Mb laravel/framework with Mockery 0.9.0 and Zend PHP 5.5.6 Time: 1.61 seconds, Memory: 66.50Mb laravel/framework with Mockery 0.8.0 and Zend PHP 5.5.6 w/xdebug Time: 5.96 seconds, Memory: 334.25Mb laravel/framework with Mockery 0.9.0 and Zend PHP 5.5.6 w/xdebug Time: 3.38 seconds, Memory: 74.00Mb laravel/framework with Mockery 0.8.0 and HHVM Time: 42.91 seconds, Memory: 388.57Mb laravel/framework with Mockery 0.9.0 and HHVM Time: 2.19 seconds, Memory: 61.80Mb
As part of the rewrite, there are also interchangeable loaders. By default we use an EvalLoader, but you can configure the container to use the RequireLoader, which will dump the code to a file and then require it, allowing easier debugging etc.
HHVM Support
We’re almost entirely there, waiting for HHVM nightlies to incorporate one last fix and travis should go green, depending on what version of phpunit they use.
Named Mocks
One fall out of the caching support was that some people where depending on class names being different, in the cases where they wanted two different derivatives of the same abstract type. We added a static `namedMock` helper method to the deal with this.
<?php
$foo = Mockery::namedMock("MockFoo", "Foo");
echo get_class($foo); // MockFoo
Quick Defs Are Automatically `byDefault`
As the quick definitions can only ever be stubs, we set them to byDefault automatically, allowing quick defs to be used in setup etc, but overriden in specific tests.
<?php
$foo = Mockery::mock("Foo", array("bar" => 123));
$foo->shouldReceive("bar")->andReturn(456);
echo $foo->bar(); // 456
PHP Security: Default Vulnerabilities, Security Omissions and Framing Programmers?
Aug 26th
15 (Photo credit: el frijole)
Secure By Design is a simple concept in the security world where software is designed from the ground up to be as secure as possible regardless of whether or not it imposes a disadvantage to the end user. The purpose of this principle is to ensure that users who are not security experts can use the software without necessarily being obliged to jump through hoops to learn how to secure their usage or, much worse, being tempted into ignoring security concerns which expose unaddressed security vulnerabilities due to ignorance, inexperience or laziness. The crux of the principle therefore is to promote trust in the software while, somewhat paradoxically, avoiding too much complexity for the end user.
Odd though it may seem, this principle explains some of PHP’s greatest security weaknesses. PHP does not explicitly use Secure By Design as a guiding principle when executing features. I’m sure its in the back of developers’ minds just as I’m sure it has influenced many if their design decisions, however there are issues when you consider how PHP has influenced the security practices of PHP programmers.
The result of not following Secure By Design is that all applications and libraries written in PHP can inherit a number of security vulnerabilities, hereafter referred to as “By-Default Vulnerabilities”. It also means that defending against key types of attacks is undermined by PHP not offering sufficient native functionality and I’ll refer to these as “Flawed Assumptions”. Combining the two sets of shortcomings, we can establish PHP as existing in an environment where security is being compromised by delegating too much security responsibility to end programmers.
This is the focus of the argument I make in this article: Responsibility. When an application is designed and built only to fall victim to a by-default vulnerability inherited from PHP or due to user-land defenses based on flawed assumptions about what PHP offers in terms of security defenses, who bears the responsibility? Pointing the finger at the programmer isn’t wrong but it also doesn’t tell the whole story, and neither will it improve the security environment for other programmers. At some point, PHP needs to be held accountable for security issues that it has a direct influence on though its settings, its default function parameters, its documentation and its lack thereof. And, at that point, questions need to be asked as to when the blurry line between PHP’s default behaviour and a security vulnerability sharpens into focus.
Please read the rest of my article hosted on readthedocs.org.
