Example

As a quick example, let's see how we can use Gentry's cache to test something that is supposed to send out emails.

Step 1: intercept what you need

This is up to you and your implementation, but the idea is that whenever something goes "outside" your application (like an email, but could also be a call to or from an external API) you implement a mock handler for that. Inside the mock, instead of performing the intended action store the intended result (or whatever value you're going to need to check on later) in the cache pool. An example:

<?php

function mockMailer($to, $message)
{
    // The real mailer would call `mail()` here:
    Gentry\Cache\Pool::getInstance()
        ->save(new Gentry\Cache\Item('mail', <<<EOT
To: $to
Message: $message
EOT
        ));
}

Step 2: assert the cached data

Then, in your actual test, retrieve the cached item:

<?php

// ...
$item = Gentry\Cache\Pool::getInstance()->getItem('mail');
yield assert($item->get() == <<<EOT
To: john@doe.com
Message: Howdy!
EOT
);

Note that per PSR-6, items are stored in the cache wrapped in an object implementing Psr\Cache\CacheInterface. Use the get method to retrieve the actual contents.

Also note that - Gentry's cache being extremely simple - anything you store will be serialized/deserialized. So take care not to store stuff like database handles (or implement proper __sleep/__wakeup methods if you must).

Use unique keys

Keys are unique (as in, per Gentry run), so any duplicate keys will overwrite existing values. This generally isn't a problem as the cache is reset before each test is run, but it's good to keep in mind when choosing keys. Apart from that, the key can be anything unique you can use in your test.