Ticket #613 (fixed bug)
Unit tests for cache adapters
- Created: 2012-01-28 17:11:52
- Reported by: Reines
- Assigned to: Franz
- Milestone: 2.0-alpha1
- Component: testing
- Priority: normal
We cannot easily test the xcache module because xcache isn't supported when running in cli mode (since xcache is per process, and in cli mode each run is a new process - it makes no sense...).
We should probably just remove its tests.
Reines 2012-01-29 11:18:12
Possible, but a pain in the ass. Unless we actually decide we want to test every single cache module I don't see any need to specifically pick out XCache to test.
Franz 2012-01-29 16:17:59
I guess I didn't add the tests for the other modules yet...
Franz 2012-02-14 12:48:53
I think Travis should allow us to install most of the cache adapters and test them?
I can try if there are no objections.
Oh, and are you saying this would not make sense for XCache anyway?
Reines 2012-02-14 13:35:06
No cache modules make sense when running from CLI, as the cache is always cleared when the process ends, which in CLI mode is after the single script has finished.
XCache explicitly refuses to run in CLI mode, which makes sense for the real world, but is a pain if we are testing using phpunit, since phpunit runs via CLI. Whether other cache modules allow running via CLI I'm not sure.
Franz 2012-02-14 14:29:18
- Owner set to Franz.
Example on how to install Memcache on Travis:
Here's how Doctrine does (or might in the future do) it for Memcache and a few others:
Franz 2012-02-14 16:50:19
- Description changed. (Diff)
It seems like there is an error with the Memcached module: http://travis-ci.org/#!/fluxbb/cache/builds/676973.
I tracked this down to the status code Memcached::HASH_FNV1_32 - no clue what that means, though.
@Reines: can you investigate?
Franz 2012-02-15 00:33:04
Adapters that can not be tested (in CLI):
Adapters that can not be installed:
Franz 2012-02-15 00:34:56
- Component changed from caching to testing.
- Summary changed from cache unit tests to Unit tests for cache adapters.
That leaves us with Memcached not working - but probably only on Travis, not in general.
Once that is sorted, we should be done.
Franz 2012-02-15 15:31:04
It seems like I made a mistake and the returned status code is Memcached::RES_WRITE_FAILURE instead - which means "Failed to write network data". Hmm.
Franz 2012-02-15 17:39:18
- Status changed from open to fixed.
Goodness gracious, after wasting more than hour with remote debugging it turns out that Memcached wants to have 127.0.0.1 as host, not "localhost". Go figure, I'm done with this stuff!!!