Weave Code
Behat Redis Context Laravel Package
macpaw/behat-redis-context
A Behat context for Redis-backed acceptance tests: clean or flush test databases between scenarios, seed and inspect keys, and keep feature suites isolated, repeatable, and free of stale test data.
Redis Context for Behat testing
Frequently asked questions about Behat Redis Context
- Is macpaw/behat-redis-context a Laravel package?
- No. It is a Behat context (MacPaw\BehatRedisContext) that you register in behat.yml, with no Laravel service provider, config binding, or package auto-discovery. It only becomes useful in a Laravel codebase when Behat is already present alongside a Laravel bootstrap extension. The real decision is adopting Behat, not installing a helper.
- How do I install Behat Redis Context in a Laravel project?
- Add it as a dev dependency with composer require --dev macpaw/behat-redis-context, then register the context in your behat.yml and point it at a Redis DSN. Behat itself must already be installed and wired to your application. Version 3.0.0 widens dependency constraints so it resolves more cleanly against current Predis and PHP versions.
- Does it support Laravel 10 and Laravel 11?
- There is no Laravel version constraint because it is not a Laravel package; compatibility is gated on Behat, PHP, and the underlying Redis client instead. The 3.0.0 release widens dependency ranges, which materially reduces the chance of a resolver conflict with the Predis and PHP versions Laravel 10 and 11 pull in. You should still confirm Redis 7+ behavior with a short spike before committing.
- How do I configure the Redis connection for each Behat suite?
- Redis connection settings are configurable per suite, so you can pass host, port, and database index through the context arguments in behat.yml. For Laravel projects, make sure those values match your testing environment's REDIS_DB and REDIS_CACHE_DB separation. Misaligned database indexes are the most common reason assertions silently fail.
- What steps does the context provide for checking keys, values, and TTLs?
- It ships ready-made steps for asserting key existence, inspecting stored values, and verifying TTLs, so cache, session, or queue state can be checked directly from feature files. There are also helpers for selecting and flushing databases between scenarios. This removes the need to write custom PHP glue for routine Redis assertions.
- How do I flush the Redis test database between scenarios?
- The context includes flush and database-selection helpers that you can invoke from Behat hooks or tagged scenarios to keep suites isolated and free of stale data. Point it at a dedicated test database index rather than your development or cache database. Tagging scenarios keeps cleanup scoped so you do not wipe data you still need.
- Why do my Redis assertions fail against a Laravel app even though the data is there?
- Laravel prefixes cache keys and separates REDIS_DB from REDIS_CACHE_DB, so raw Redis assertions look at the wrong key names unless the context is configured to match Laravel's naming conventions. Check the key prefix, the database index, and any cache store prefix before debugging the package itself. This Laravel-specific risk is unchanged by the 3.0.0 release.
- What breaking changes are in version 3.0.0?
- The release widens dependency constraints to support current packages and resolves the PHPStan 2.x upgrade, but the notes do not enumerate breaking changes. A major bump alongside widening usually means a raised minimum PHP, Behat, or Predis version and possibly changed constructor or step signatures. Read the changelog diff, the composer.json constraint delta, and the context signatures before upgrading from 2.0.1.
- What are alternatives to using Behat Redis Context?
- If Behat is not already in your stack, staying on PHPUnit or Pest and asserting through Laravel's Redis facade or cache API is usually far cheaper than adopting a whole BDD framework. If Behat is already present, a small custom context wrapping Predis covers the same key, value, and TTL checks. This package is a convenience for existing Behat suites, not a requirement.
- Is it safe to use in production and is it well maintained?
- It is a dev-only dependency with zero production footprint, so runtime risk is minimal. Maintenance risk is the real concern: low star count, no dependents, single-organization stewardship, and a bus factor of one, though 3.0.0 added a second named contributor. The test surface is thin, with four PHPUnit tests that never exercise a live Redis server, so behavior against real DB indexes, key prefixes, and cluster or sentinel setups remains unproven.
Weaver
How can I help you explore Laravel packages today?