Behat Tools Bundle Laravel Package

Getting Started

First, calibrate expectations: this is a Symfony bundle, not a Laravel package. There is no service provider, no config/behat_tools.php, and no facade. As a Laravel developer you have two realistic paths:

1. Use it only inside a Symfony application (the intended target), where it plugs into the kernel.
2. Mine it for patterns — read the controllers/services and reimplement the small amount of "feature management" logic natively in Laravel (a route + Blade view that scans tests/Feature/*.feature or features/). Given the package's size (5 stars, 0 dependents), this is usually the pragmatic choice.

Minimal Symfony setup if you go path 1:

composer require halleck45/behat-tools-bundle

• Register the bundle: new Halleck45\BehatToolsBundle\BehatToolsBundle() in app/AppKernel.php (Symfony 2/3) or config/bundles.php (Symfony 4+).
• Import its routing (check Resources/config/routing.yml for the actual prefix).
• Add a behat_tools: block to your config pointing at your features directory and Behat binary. Read DependencyInjection/Configuration.php first — that file is the authoritative list of options, not the README.
• Clear the container cache (bin/console cache:clear) and hit the route it exposes.

Where to look first, in order: Configuration.php → the controller → Resources/views/ → Resources/config/routing.yml. That's the entire surface area of a bundle this size.

First use case: point it at features/ and get a browsable inventory of .feature files and scenarios in a web UI, instead of grep -r "Scenario:" across the repo.

Implementation Patterns

• Dev-only registration. Register the bundle and its routes only in the dev environment, and put the route behind your existing firewall/access_control. A web UI that lists and possibly executes tests is an internal tool, not a production endpoint.
• Treat it as a read-only inventory first. The highest-value, lowest-risk use is listing features, scenarios, and tags. Anything that executes Behat by shelling out is where you should stop and audit the code before enabling it.
• Config-driven paths. Keep the features directory and Behat binary in config rather than hardcoding, so the same bundle works across projects and CI-adjacent environments.
• Feature-file convention discipline. The bundle assumes a directory layout; standardize on features/<domain>/<thing>.feature with tags (@wip, @smoke) so listing/filtering is meaningful. Garbage in, garbage inventory out.
• Don't put it in CI. CI should invoke behat (or php artisan behat equivalents) directly with explicit exit codes. A web UI is for humans browsing locally.
• Laravel port pattern. If reimplementing: a single Route::get('/dev/features', ...) in a dev-only route file, a controller that globs base_path('features/**/*.feature') or tests/**/*.feature, a lightweight parser (regex on Feature:, Scenario:, @tags), and a Blade view. ~100 lines, zero dependency risk, and it matches Laravel conventions instead of fighting Symfony's.
• Extend via templates, not forks. If you must customize the UI and the bundle uses standard Symfony templating, override views in app/Resources/BehatToolsBundle/views/ (or templates/bundles/... on newer Symfony) rather than editing vendor code.

Gotchas and Tips

• Version compatibility is the big one. A 5-star bundle with 0 dependents is almost certainly frozen in the Symfony 2/3, PHP 5.x era. Expect composer require to fail on modern PHP/Symfony constraints. Check the composer.json require block before promising anyone a demo. If it installs at all, pin it and commit the lockfile.
• No Laravel integration exists. No Illuminate\Support\ServiceProvider, no config publishing, no artisan commands. Any "it works in Laravel" claim you see is someone wrapping it manually.
• Command execution risk. If the bundle exposes a "run this scenario" action, it likely shells out to the Behat binary. Audit for argument injection and confirm it's gated to dev. Never expose this route publicly.
• Path resolution is relative to the kernel root, not the bundle or the CWD. If features aren't showing up, log the resolved absolute path — nine times out of ten it's a path/config mismatch, not a parsing bug.
• Container/cache weirdness. After changing behat_tools config, always cache:clear. Symfony caches compiled container config aggressively, and stale config produces silent empty listings.
• Debugging checklist: (1) bin/console debug:router | grep -i behat — is the route even registered? (2) bin/console config:dump-reference behat_tools — does your config key match the schema? (3) debug:container for the bundle's services — are they public/instantiated?
• Extension points are thin. Realistically: template overrides, and decorating/overriding the bundle's services in your own services.yml. Don't expect event hooks or a plugin system.
• Maintenance reality. 5 stars, 0 dependents, single author. Treat it as an unmaintained reference implementation. Budget for forking, and prefer reimplementation in Laravel over adoption if the feature set is small (which, for "manage your features," it likely is).
• Documentation is the code. Don't trust the README for config keys; the Configuration.php tree and the controller signatures are the truth.