On the Laravel News site there's a tutorial helping you learn to use Model factories in your Laravel 5.1+ application. These factories make it easy to create instances of "fake" models that can be interacted with as if they were the real thing.

These have several use cases with the two biggest being–testing and database seeding. Let’s take a deeper look at this feature by building out the beginning of a little fictional app.

They provide a situation where these factories can solve a potential problem: making an application easier to test because of the (potentially) high volume of customers. He walks you through the creation of a new application and building out the models and matching migrations. Next up is the generation of the database seed values and, finally, the creation of the fake models and the code needed to connect it all together. The post ends with a look at using these factories to generate models in tests, creating them with simple data and some of the other features they offer.

Phil Bennett has a new post today talking about a way that you could use dependency injection in your testing, making it easier to work your system by using stubs, fakes and mocks.

Dependency injection is a simple design pattern that provides several benefits, one of which is the ability to vastly improve your unit test suite. In this post I am going to be looking at how this is done and how it relates to certain testing methodologies.

He talks some about the refactoring of an application to allow for easier dependency injection and how, while easier, can still make it difficult to abstract out things like database functionality. Instead, he suggests creating "fake" classes that model the behavior of the needed dependency. He shows examples of each type - a fake, stub and mock - and talks some about the differences between each (and situations one might be used over the other).

The Inviqa techPortal has a new post today from Marcello Duarte about using Prophecy in unit testing to work with mocks and doubles.

Test doubles are a way of replacing all classes in our tests other than the one we are testing. They give us control on direct and indirect outputs that would have been generated by those classes. Understanding the role of the test double helps us to write better tests, and thus better code. [...] When writing unit tests we are focusing on describing one unit of behaviour at a time, and how objects communicate in order to achieve that behaviour. We instantiate the object under test, call a method of the object and observe if the outcome is as expected.

In his examples he uses Prophecy to mock out different kinds of objects - a dummy object, a "fake" (with listeners for other object calls), a stub that mocks other internal method calls and a more familiar mock object. He also talks about two guidelines to follow when thinking about writing tests and code complexity - the Law of Demeter and "Don't Mock What You Don't Own." He gives an example of working around this last one by using the Adapter design pattern.

In a new post over on DZone.com Giorgio Sironi shows how to create a fake, an interface that mocks the interface to an external tool and provides cached results back to the calling script.

We can specialize our Fake in a Self-Initializing Fake, which will provide an alternative implementation with the aid of the real one. In our Google Maps case, the Fake will use the real web service for its first response, and maintain an internal cache. This mechanism provides insurance about out-of-sync responses, and lets you enjoy the speed of unit tests after the initial warmup: if you always use the same data, no duplicate requests will be made to the external resource.

He includes example code for creating a test (with PHPUnit) that loads in the information from the Google Maps web service and caches it into a private variable inside the Fake. His test fails the first time checking for a difference in the time between fetching the real version and the cached version (fails the first time, but passes after the cache is implemented).

In a recent post to his blog Ian Barber looks at applying Benford's Law in PHP to determine if the dataset you're working with is "real" or not.

Benfords Law is not an exciting new John Nettles based detective show, but an interesting observation about the distribution of the first digit in sets of numbers originating from various processes. It says, roughly, that in a big collection of data you should expect to see a number starting with 1 about 30% of the time, but starting with 9 only about 5% of the time.

He pulls data from the data.uk.gov site to illustrate and includes a simple PHP script to run through the data looking scoring it with a "Benford" rating. He plots these on a graph along side the data to show the (almost exact) match between the data and the Benford numbers. You can find more details on the law on Wikipedia.

Mikko Koppanen has posted about an extension he's written up that has only one real purpose - to help with unit testing a script with a file upload involved (making a "fake upload" possible).

The extension is doing things that shouldn't be done, it probably doesn't even run anywhere else than on CLI, it is insecure, it might behave incorrectly but in this scenario it worked fine so I decided to share it.

This "use at your own risk" extension gives you a new function to use instead of the normal move_uploaded_file, appropriately named "fakeupload_file". It creates the fake file so that even calls to is_uploaded_file will see it as if it was correctly on the file system. An unlink is all that's needed to remove the "file".

Alexey Zakhlestin shares with us in this new blog post, how the fast-cgi PHP developers think they're using isn't really a true FastCGI.

He talks about a history of how things go to where they are, starting back with regular CGI scripts, moving up through using server-based APIs, and finally to FastcGI, a method for overcoming a lot of the limitations of its predecessors.

With that look back, he turns his attention around and looks to the current situation within PHP. He talks about the sudden appearance fastcgi made in PHP's SAPIs, but that the implementation wasn't true. He suggests that the reasoning behind this "fake" implementation was for the sake of speed. He also notes, however, it's his opinion that true FastCGI support in PHP will be a requirement for future large-scale applications.

Alexey Zakhlestin shares with us in this new blog post, how the fast-cgi PHP developers think they're using isn't really a true FastCGI.

He talks about a history of how things go to where they are, starting back with regular CGI scripts, moving up through using server-based APIs, and finally to FastcGI, a method for overcoming a lot of the limitations of its predecessors.

With that look back, he turns his attention around and looks to the current situation within PHP. He talks about the sudden appearance fastcgi made in PHP's SAPIs, but that the implementation wasn't true. He suggests that the reasoning behind this "fake" implementation was for the sake of speed. He also notes, however, it's his opinion that true FastCGI support in PHP will be a requirement for future large-scale applications.