Behat Wizard Bundle Laravel Package

Getting Started

1. Install with Composer (expect to fight constraints — the bundle is from the Symfony 2/3 era, so you may need --ignore-platform-reqs or an explicit version constraint):

   composer require --dev halleck45/behat-wizard-bundle
   

2. Register the bundle in app/AppKernel.php (Symfony 2/3) inside the dev environment block only:

   if (in_array($this->getEnvironment(), ['dev', 'test'])) {
       $bundles[] = new Halleck45\BehatWizardBundle\BehatWizardBundle();
   }
   

3. Import the routing in app/config/routing_dev.yml:

   behat_wizard:
       resource: "@BehatWizardBundle/Resources/config/routing.yml"
       prefix:   /_behat
   

4. Configure the features path (and, if the bundle runs Behat for you, the binary path) under behat_wizard: in config_dev.yml. Look at Resources/config/ and the bundle's README for the exact keys — they are not extensively documented.
5. Install assets if the bundle ships its own CSS/JS: php app/console assets:install web --symlink.
6. First use case: open /_behat in your browser, browse the list of .feature files under features/, open one, edit a scenario, and save. The wizard writes directly to disk — check git diff immediately after your first save to confirm the path and formatting are what you expect.

Where to look first: vendor/halleck45/behat-wizard-bundle/Resources/config/routing.yml for the real route names, and the bundle's DependencyInjection/Configuration.php for the supported config keys.

Implementation Patterns

• Keep it strictly a dev tool. Enable the bundle and its routes only in dev, and front the routes with an access_control rule or an IP allowlist. This is a web UI that edits files on your filesystem; it has no place in staging or production.
• Treat the filesystem as the source of truth. The wizard is an editor, not a database. Your normal workflow stays: write/edit Gherkin in the UI → save to features/*.feature → review in git diff → commit. Never let the UI become the only place a feature exists.
• Pair the UI with the CLI. Use the wizard for authoring and quick feedback, and keep vendor/bin/behat (plus --dry-run) as the gate in CI. The wizard does not replace behat.yml, context classes, or step definitions.
• Point it at a dedicated directory. Configure features_path at your existing features/ folder so the wizard and Behat agree on layout. If you have multiple suites, run a separate instance/config per suite rather than trying to make one wizard cover everything.
• Use it as a step-discovery aid. The most valuable day-to-day use is jumping from a failing/undefined step to the relevant feature and context. Open the feature in the UI, adjust the scenario, then implement the step in PHP in your IDE.
• Version-pin the bundle. Because it is effectively unmaintained, lock the version in composer.json and commit composer.lock so a fresh composer install on another machine does not silently resolve to a broken combination.
• Override, don't fork, where possible. Symfony's bundle inheritance lets you override templates under app/Resources/BehatWizardBundle/views/ for small UI tweaks; reserve a fork for anything touching the file-writing or execution services.

Gotchas and Tips

• Compatibility is the main risk. The bundle targets old Symfony (2.x) and Behat (2/3) APIs and old PHP versions. On Symfony 4+ or PHP 8 you will likely hit container, routing, or type-hint errors. Check composer.json constraints before planning adoption; if they don't fit, budget a fork or pick a different tool.
• File permissions. The web server user must be able to write to features/. If saves silently fail or produce permission errors, check ownership of the directory and any SELinux/AppArmor restrictions.
• Path resolution. features_path is resolved relative to the project root in most configs; use an absolute path if you see "not found" errors from the console but files exist. Watch out for symlinked features/ directories.
• Binary and timeouts. If the bundle shells out to behat, make sure the configured PHP/Behat binary is the one your CLI uses (same PHP version, same vendor/), and expect long-running suites to hit PHP max_execution_time. Prefer running suites from the CLI and using the UI just for authoring.
• Cache and assets. After changing config or routes, clear the dev cache; after upgrading the bundle, re-run assets:install. Stale assets are a common cause of a "blank" UI.
• Security review before exposing. The routes can read and write arbitrary files under the configured path and may execute a binary. Add a firewall entry, restrict by IP, and consider disabling the run/execute feature entirely if it exists in your version.
• Step autocomplete depends on loadable contexts. If step suggestions are empty, the bundle can't bootstrap your Behat contexts — check that behat.yml is valid and context classes autoload correctly.
• Debugging: enable the Symfony profiler and check var/logs/dev.log; most failures are config keys, permissions, or a missing route import rather than bugs in the bundle itself.
• Extension points are thin. Realistically you get template overrides and service decoration. If you need meaningful customization (custom step generation, multiple projects, API integration), plan for a small internal replacement rather than stretching this bundle.
• Alternatives worth considering: IDE/editor plugins (VS Code Cucumber/Gherkin, PhpStorm Behat support) usually give better day-to-day ergonomics with none of the hosting and security overhead. Choose this bundle only if a browser-based editor for non-developers (PM/QA) is an explicit requirement.