The QaFoo.com blog has a new post sharing a helpful hint on refactoring singletons to make them more testable. Singletons and notoriously difficult to test due to how it can potentially return an unexpected version of an object.

So your code base is littered with singletons and using them? Don't worry, you can start refactoring them out of your code base class by class and introduce increased testability at every step. This strategy is very simple to implement and the probability of breaking your code is very low, especially when you are becoming more experienced with this technique.

They give an example of a service class that uses a singleton to get an instance of the Solarium_Client class via a static method call. They show how to refactor this out into a separate method and then use the "lazy initialization" pattern to only use the singleton if the property isn't already defined. This then allows you to use a setter to inject your own client during testing (a mock most likely).

Loïc Faugeron has posted the next part of his "Mars Rover" series with the initialization of the project and taking some first steps with modules.

In this series we're going to build the software of a Mars Rover, according to the following specifications. It will allow us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES), Test Driven Development (TDD)

But first, we need to initialize our project.

He walks through the creation of the initial repository with a composer.json configuration and commits the initial version. From there he creates the "navigation" package that will handle write-only and read-only functionality to "drive" the rover around. He creates this package and a matching phpspec configuration file for testing the codebase. He then adds the navigation package to the main project though a branch merge.