php-cache / integration-tests

Integration tests for your PSR-6 cache implementation

PSR-6 and PSR-16 Integration tests

This repository contains integration tests to make sure your implementation of a PSR-6 and/or PSR-16 cache follows the rules by PHP-FIG. It is a part of the PHP Cache organisation. To read about us please read the shared documentation at www.php-cache.com.

Install

composer require --dev cache/integration-tests:dev-master

Use

Create a test that looks like this:

class PoolIntegrationTest extends CachePoolTest
{
    public function createCachePool()
    {
        return new CachePool();
    }
}

You could also test your tag implementation:

class TagIntegrationTest extends TaggableCachePoolTest
{
    public function createCachePool()
    {
        return new CachePool();
    }
}

You can also test a PSR-16 implementation:

class CacheIntegrationTest extends SimpleCacheTest
{
    public function createSimpleCache()
    {
        return new SimpleCache();
    }
}

Contribute

Contributions are very welcome! Send a pull request or report any issues you find on the issue tracker.

integration-tests's Issues

Tag and update to phpunit 8?

So I tried extending the test-suite to run under Codeception - not really meaningful, since Codeception requires a different base-class to enable Codeception features, including configuration.

I dropped Codeception and decided to move to a plain PHPUnit test-suite instead - also without luck, as the test-suite doesn't have the void return-type on SimpleCacheTest::setUp(), failing the build under PHP 7.2.

So now it's down to running a very old version of PHPUnit to be able to reuse this test-suite.

I'd like to suggest:

1. Tag a release 1.0.0
2. Upgrade requirement for phpunit to ^7|^8
3. Upgrade requirement for php to ^7
4. Tag a release 2.0.0

For now, I'm going to fork the package so I can use it with a current version of PHPUnit myself.

Would you like a PR for the changes?

Questions regarding `CachePoolTest#testHasItemReturnsFalseWhenDeferredItemIsExpired`

Hey guys,

I have a question regarding the test mentioned in the title.
When I use a TTL for a cache item, does the TTL start "expiring" from the moment it is set to the cache item, to the CachePool or when it is finally stored to the cache backend?

This is very confusing as the test actually assumes that it has to start "expire" when passed to the CachePool which I think is kinda - weird.

Can someone enlighten me please? Maybe with a reference to the relevant parts in the PSR. Thanks!

Conflicting tests?

I am probably misunderstanding the point of one or both of these, but the following two tests appear to be in conflict with each other.

1) PoolIntegrationTest::testSaveDeferredWhenChangingValues
Items that is put in the deferred queue should not get their values changed
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'value'
+'new value'

/home/jordan/git_repos/RW-File-Cache-PSR-6/vendor/cache/integration-tests/src/CachePoolTest.php:832

1) PoolIntegrationTest::testSaveDeferredOverwrite
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'new value'
+'value'

/home/jordan/git_repos/RW-File-Cache-PSR-6/vendor/cache/integration-tests/src/CachePoolTest.php:856

Assuming this is not an issue, could someone help me clarify the intentions of these two tests?

Many thanks.

PHP 8.0 support

Hey there,

is there already any plan regarding PHP 8.0 support (and thus, phpunit 9.3 support)?
Is there anything I can help with?

Incorrect call in SimpleCacheTest::testSetMultiple

Within SimpleCacheTest::testSetMultiple(), the test makes the following call:

$result = $this->cache->setMultiple(['0' => 'value0']);

and later:

$this->assertEquals('value0', $this->cache->get('0'));

I assert that the original setMultiple call should fail. PHP silently converts string array keys that contain integers to integers; thus, '0' will become 0, which PSR-16 would consider an invalid key. (See this example on 3v4l for confirmation.)

The test should use valid string keys:

$result = $this->cache->setMultiple(['key0' => 'value0']);
// ...
$this->assertEquals('value0', $this->cache->get('key0'));

Add documentation about how to skip tests

Reminder: Add mockery to require-dev

Move to namespaced PHPUnit

Required on Symfony where we already use phpunit 6 on the php 7.1 matrix line.
We have to skip the cache test suite for now.

Should the expiration value remain after second save?

Consider this:

// T = 0
$item = $pool->getItem('key');
$item->set('value');
$item->expiresAfter(3600);
$pool->save($item);

// T = 600
$item = $pool->getItem('key');
$item->set('foobar');
$pool->save($item);

For how long is the item still in cache? The way I see it there are three options:

• A) Until T=3600
• B) Until T=4200
• C) Forever since $item->expiresAfter() was never called.

I believe that option A is preferable.

This question has a lot of impact on performance. If C is the right way we do not have to read to the cache before doing a store.

Remove "BasicUsage" tests

Does it give anything that other tests does not have?

Usage of symfony/phpunit-bridge has broken downstream consumers (maybe?)

I tried updating to the latest of cache/integration-tests (since we use the Cache\IntegrationTests\SimpleCacheTest in our test suite to validate roave/doctrine-simplecache is compatible with other Simple Cache implementations).

https://github.com/Roave/DoctrineSimpleCache/blob/9f908c7b707d36d56a4ab63d6979e93173b069bc/test/unit/CacheIntegrationTest.php#L6-L21

However, I note that the latest now uses a trait Symfony\Bridge\PhpUnit\SetUpTearDownTrait:

integration-tests/src/SimpleCacheTest.php

Lines 16 to 20 in e023fbe

	use Symfony\Bridge\PhpUnit\SetUpTearDownTrait;
	abstract class SimpleCacheTest extends TestCase
	{
	use SetUpTearDownTrait;

symfony/phpunit-bridge is only a require-dev dependency of cache/integration-tests so I had to add this manually. So I did composer require --dev symfony/phpunit-bridge which picked ^4.3... however looking through the tags at https://github.com/symfony/phpunit-bridge/tree/v4.3.5, this SetUpTearDownTrait doesn't seem to be included, even though it does exist in master.

Two queries here: why is symfony/phpunit-bridge required now for these integration tests? Why are we binding this library to a specific framework package, when this should be generic and apply to all frameworks? Secondly: if it really is necessary and never going to go away, how can I resolve this dependency mess? It's really unclear and confusing what symfony/phpunit-bridge serves, and why it even exists here :/ plz send halp 😁 thank you!

When will be next release?

Impossible to use the tests because I already must extend another TestCase.

Would it be possible to move the test methods into a trait?

I'm currently working on a WordPress object cache => psr16 adapter which unfortunately requires booting WordPress. Thus I have to extend another test case already and can't use the provided test case from this package.

Right now the only option I have is to copy all test methods.

Integer keys

The function SimpleCacheTest::invalidKeys() line 58 lists (integer) 2 as invalid key, which leads to a problem:

1. PHP will read ['0' => 'value0'] as ['value0'] making it impossible to determine whether 0 was an integer or a string at declaration time. Reference: PHP documentation on arrays, stating A key may be either an integer or a string. If a key is the standard representation of an integer, it will be interpreted as such (i.e. "8" will be interpreted as 8, while "08" will be interpreted as "08").
2. Considering point 1, the test case SimpleCacheTest::testSetMultipleWithIntegerArrayKey() line 225 effectively considers 0 a valid key, contradicting SimpleCacheTest::invalidKeys().
3. The problem already seems to have surfaced, because there is a fix in SimpleCacheTest::testSetMultipleInvalidKeys() on line 461. However, this does not solve the problem, because the tests using the SimpleCacheTest::invalidKeys() function still consider (integer) 2 an invalid key.

To solve the problem, either integers are considered keys, or the the test case SimpleCacheTest::testSetMultipleWithIntegerArrayKey() line 225 uses another key than '0'.

Max Key Length

There is a test testBasicUsageWithLongKey which checks for keys of 300 chrs in length. This test is breaking for me.

It looks like its because the max key is limited by php_memcached to 250 chrs. see MEMC_OBJECT_KEY_MAX_LENGTH in https://github.com/php-memcached-dev/php-memcached/blob/master/php_memcached.c

If I manually change the key length to 250 everything passes. Was there a reason why this is checking for 300chr keys?

PSR-16 doesn't mention InvalidArgumentException for invalid TTL

The current PSR-16 integrations tests expect an InvalidArgumentException to be thrown[1] when passing an invalid $ttl. I think that is wrong, or at least premature. The spec does not specify[2] what should happen in the case of invalid input and leaves that up to the library.

There is a PR[3] to make it official that an invalid TTL results in an InvalidArgumentException. However, it has not been merged in a month.

There is another PR[4] (to PSR-6, but I assume PSR-16 to follow suit should it pass) to throw a TypeError (or trigger_error). It's been around for longer, but could be brought back up with FIG 3 in place.

In short: I don't think this behavior for TTL should be enforced, since 1) it's undefined in the spec, and 2) there are competing ideas on how to eventually define it in spec.

1: https://github.com/php-cache/integration-tests/blob/master/src/SimpleCacheTest.php#L509
2: https://groups.google.com/forum/#!topic/php-fig/TQX0-DpKTKM
3: php-fig/fig-standards#858
4: php-fig/fig-standards#787

FatalErrorException with PHPUnit 8.4.3 and PHP 7.3

The signature obviously has changed. See sebastianbergmann/phpunit@f5e5add

Fatal error: Declaration of Cache\IntegrationTests\CachePoolTest::setUp() must be compatible with PHPUnit\Framework\TestCase::setUp(): void in /home/travis/build/pimcore/pimcore/vendor/cache/integration-tests/src/CachePoolTest.php on line 896
In CachePoolTest.php line 896:

[Symfony\Component\Debug\Exception\FatalErrorException]
Compile Error: Declaration of Cache\IntegrationTests\CachePoolTest::setUp()
must be compatible with PHPUnit\Framework\TestCase::setUp(): void

Skipped test in SimpleCacheTest::testSetMultipleInvalidKeys()

In SimpleCacheTest::testSetMultipleInvalidKeys() line 461:

        if (is_int($key)) {
            $this->markTestSkipped('As keys, strings are always casted to ints so they should be accepted');
        }

This leads to test output like the following:

OK, but incomplete, skipped, or risky tests!
Tests: 208, Assertions: 307, Skipped: 1.

Skipping is the wrong thing to do here - this isn't strictly a skipped test; it wasn't "incomplete or risky", it's just that the test started with the wrong dataProvider.

I'd suggesting adding another data-provider method e.g. invalidKeysExceptInt(), that calls invalidKeys() and removes the integer value before attempting to run the tests, so we don't end up with this misleading message from the test-runner.

Any objections, or can I submit a PR?