PHPackages                             pseudo/pseudo - PHPackages - PHPackages  [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register)

1. [Directory](/)
2. /
3. [Testing &amp; Quality](/categories/testing)
4. /
5. pseudo/pseudo

ActiveLibrary[Testing &amp; Quality](/categories/testing)

pseudo/pseudo
=============

A system for mocking PHP PDO connections

3.0.0(5mo ago)012.9k↑83.3%1[3 issues](https://github.com/ActuallyConnor/pseudo/issues)MITPHPPHP &gt;=8.2CI passing

Since May 6Pushed 5mo ago1 watchersCompare

[ Source](https://github.com/ActuallyConnor/pseudo)[ Packagist](https://packagist.org/packages/pseudo/pseudo)[ RSS](/packages/pseudo-pseudo/feed)WikiDiscussions main Synced 1mo ago

READMEChangelog (10)Dependencies (5)Versions (28)Used By (0)

Pseudo
======

[](#pseudo)

Introduction
------------

[](#introduction)

Pseudo is a system for mocking PHP's PDO database connections. When writing unit tests for PHP applications, one frequently has the need to test code that interacts with a database. However, in the true spirit of a unit test, the database should be abstracted, as we can assume with some degree of certainty that things like network links to the database server, the database connection drivers, and the database server and software itself are "going to work", and they are outside the scope of our unit tests.

Enter Pseudo. Pseudo allows you to have "fake" interactions with a database that produce predefined results every time. This has 2 main advantages over actually interacting with a database. First, it saves having to write data fixtures in another format, ensuring the data schema availability, loading the fixtures in, and then later cleaing and resetting them between tests. Second, and somewhat as a result of the first, tests can run *significantly* faster because they are essentially talking to an in-memory object structure rather than incurring all the overhead of connecting and interacting with an actual database.

The general idea is that Pseudo implements all the classes in the PDO system by inheriting from them and then overriding their methods. During your test, at the point where you would inject a PDO object into your data layer, you can now inject a Pseudo\\Pdo object transparently, giving yourself 100% flexibility to control what your application now *thinks* is the database. In your unit test, you can express the mocks for your test in terms of SQL statements and arrays of result data.

Find the package on [packagist.org](https://packagist.org/packages/pseudo/pseudo)

Documentation
-------------

[](#documentation)

### Documentation Generation

[](#documentation-generation)

This project uses [readthedocs](https://readthedocs.io) and [mkdocs](https://mkdocs.org)

To load the local documentation page setup mkdocs locally and run:

```
$ mkdocs serve
```

You can edit the `mkdocs.yaml` file to change the pages that show up in the sidebar.

To generate the docs, setup [phpDocumentor](https://phpdoc.org/) locally and then run:

```
$ phpdoc --directory=src --target=docs --template="vendor/saggre/phpdocumentor-markdown/themes/markdown"
```

Installation
------------

[](#installation)

```
composer require --dev pseudo/pseudo

```

### Usage

[](#usage)

#### Something you may want to test

[](#something-you-may-want-to-test)

```
