Unit testing is something that I'm still rough around the edges with. I don't do it nearly enough at work and never really pushed myself to pick it up on the side. With my core site refactor, though, it seemed like a good time to wander into testing. And it made a lot of sense to write unit tests around the new domain repository classes I was building out.
As a quick refresher, a repository is merely an encapsulation of the business logic that defines a collection. Or, you know, a query. The application makes a call out to a method, that method performs a query (or another storage-specific data retrieval operation) based on the domain, and then some sort of collection is returned. In order to test a repository there needs to be a storage area with mocked data to check to make sure the business logic is being respected.
Right now I only have MySql-based repository objects, each of which hold onto a few queries, so I needed a way to mock up a MySql-like storage area. Luckily there is a great transient solution for this: in-memory SQLite. I could create a handful of mock tables in memory, test my repository object, and then flush them out of existence.
// example class and method to be tested
class MysqlExampleRepository implements ExampleRepositoryInterface
public function __construct($db)
$this->db = $db;
public function getRow($id)
$query = "
SELECT `id`, `title`
WHERE `id` = :id";
$bindings = [
'id' => $id,
// test class
class MysqlExampleRepositoryTest extends PHPUnit_Framework_TestCase
public function __construct()
$this->db = new ExtendedPdo('sqlite::memory:');
CREATE TABLE IF NOT EXISTS `example` (
`id` integer PRIMARY KEY AUTOINCREMENT,
`title` varchar(60) NOT NULL
public function testGetRow()
$test_data = [
'id' => 1,
'title' => 'Hello World',
INSERT INTO `example`
$repository = new MysqlExampleRepository($this->db);
$fetched_data = $repository->getRow($test_data['id']);
public static function tearDownAfterClass()
As the repository objects grow larger it may make sense to create data sources to automate the hydration part, but the basic gist is to create a mirror copy of the table in SQLite and then inject the connection into the repository for testing. This only works if the queries are cross-engine friendly, of course. Anything too complex or too fine-tuned for a certain flavor of SQL would need some special attention. This is when something like a query builder could come in handy.
Now, there are two things that I'm struggling with for my implementation. The first is that my repository objects always have a domain defined in the query. In SQLite a new database means a new file, and a named database means a named file means that the in-memory option won't work. To get around this I merely switch databases with the 'ATTACH DATABASE' command and then do an unlink during 'tearDownAfterClass'. Not my favorite, but it works.
The other thing I'm struggling with is the storage engine injection. I'm using Aura.Sql and have found it convenient to pass in an instance of Aura\Sql\ConnectionLocator into my repository objects. But now I need to mock up some PDO instances, pass them to a ConnectionLocator, and then pass that around. I may switch to injecting PDO instances into the repositories, yet even that would feel better if PHP offered a PDOInterface. I'm still on the fence with which way to go moving forward.
Anyways, that's the basics on testing PHP repositories. For more examples you can check out my framework on Github, which is still under active development.