In a post to his site Tomas Votruba provides a guide "for dummies" to using local packages along side your remote packages via Composer.

I wrote about pros and cons of local packages before. After year of using this in practice and mentorings I polished this approach to even simpler version that is easy to start with.

[...] There is no need to use Github, love open-source, understand package design or understand composer beyond PSR-4. No symlink issues, no forgotten composer update. Anyone can start using this!

The "dummy" packages he creates are essentially a simulation of a Composer package just in a different location (under a "packages" directory). This can then be autoloaded via the same Composer configuration you already use without too much trouble.

Jeff Madsen has a quick post to his site showing how to use Faker to populate data in Laravel directly in the framework's generated "seeders".

Hello, Mr. asdfgh qweefg! Welcome to kgjhjgjh! Thank you. Only the name's not "asdfgh qweefg".

Sorry! It's just easier.. You're always showing everyone on Laravel Quick Tips these helpful little tricks. Why not show them how to give me a proper name?

He includes an example of creating a Faker object in the seeder and using it to make name, email, age and city values. Naturally, not everyone's going to have English names or locations, so he shows how to set the language, locale and a few other tips:

• shortcuts for optional data
• randomized email addresses
• random elements from a given set

He also mentions custom providers but points to the Faker documentation for a bit more information about that.

On thePHP.cc blog today Sebastian Bergmann has posted about the new release of PHPUnit (4.5) and how it now comes with support for the Prophecy mocking tool.

PHPUnit has had built-in support for creating test doubles for many years. This implementation was originally inspired by the first generation of mocking frameworks for Java. Since then mocking frameworks have evolved. Modern mocking frameworks are more intuitive to use, lead to more readable code, and may even allow for a clear separation of a test double's configuration and the actual test double object itself.

Like many users of PHPUnit I am not satisfied with the API of PHPUnit's own mocking framework. This dissatisfaction has lead to the development of alternative mocking frameworks for PHP such as Mockery, Phake, or Prophecy. If I were to create a new mocking framework today it would probably look a lot like Prophecy. Which is why PHPUnit 4.5 introduced out-of-the-box support for it.

He gets into some of the basics of the Prophecy tool and how it handles mocking differently than the current internal mocking PHPUnit provides. Some code examples are included showing dummies, stubs and mocks with an example of the output when some of the "predictions" have failed.

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.