- Can I use kunstmaan/behat-bundle in a Laravel application?
- No. It is a Symfony bundle built for Kunstmaan CMS acceptance tests, with no Laravel service provider, facade, or Laravel-native testing integration. It only makes sense if your stack already runs Symfony, Behat 3, Mink, and a Selenium-backed driver. For Laravel apps, evaluate Laravel Dusk, Pest browser testing, Cypress, or Playwright instead.
- What features does kunstmaan/behat-bundle provide?
- It adds reusable Behat contexts and step definitions for testing page parts, forms, and content in Kunstmaan CMS. The useful pieces are a thin layer over MinkContext: automatic screenshots on failed steps, an Ajax-settled wait, and convenience assertions such as assertPageContainsText(). It is testing-tier only and has no production runtime footprint.
- How do I install kunstmaan/behat-bundle?
- You would normally install it with Composer, but the package is a read-only subtree split of the KunstmaanBundlesCMS monorepo and carries old Behat and Symfony constraints. Expect Composer resolution to fail on a current stack, forcing --ignore-platform-reqs or a fork. You must also register the bundle in the test environment, either via config/bundles.php under Symfony Flex or a manual test kernel edit.
- Is kunstmaan/behat-bundle compatible with PHP 8.2 and PHP 8.3?
- There is no official PHP 8 support. The last release was 2014-04-05, and the context base classes are likely to surface signature and deprecation errors on PHP 8.2 or 8.3. Running it would require a maintained fork with explicit compatibility fixes.
- Which Behat and Symfony versions does kunstmaan/behat-bundle support?
- It was written against Behat 2.x and 3.x-era extension APIs and pre-Flex Symfony bundle conventions. That means manual AppKernel or bundles.php registration and older DI compiler passes rather than modern Symfony auto-wiring. Its Composer constraints almost certainly cap below what a current Symfony and Behat stack resolves to.
- Does kunstmaan/behat-bundle work with Laravel Dusk, Pest, or PHPUnit?
- No. The bundle is tied to Behat, Mink, and a Selenium or ChromeDriver-backed browser session; it does not provide PHPUnit, Pest, or Laravel Dusk integration. If your acceptance layer is Laravel-native, architectural fit is effectively zero. Do not introduce it as a dependency for Laravel testing.
- What are alternatives to kunstmaan/behat-bundle for screenshots on failure and Ajax waits?
- For Behat and Mink stacks, use maintained options such as FriendsOfBehat/MinkExtension, a Behat screenshot extension, or dmore/behat-chrome-extension. For Laravel teams, Laravel Dusk, Pest browser testing, Cypress, or Playwright cover screenshot-on-failure and network-idle or Ajax-wait behavior natively. Reimplementing the bundle's few useful behaviors in first-party context classes is usually simpler than forking it.
- Is kunstmaan/behat-bundle abandoned or maintained?
- It is abandoned for practical purposes: the last release was 2014-04-05, there is no security feed, and there is no maintainer response path. It also has zero dependents, so there is no downstream community exercising compatibility or sharing fork maintenance. Treat any adoption as owning a fork indefinitely.
- Should I use kunstmaan/behat-bundle in production?
- It is testing-tier only and injects nothing into the production application container beyond test-environment registration. The production concern is not runtime risk but CI risk: abandoned dependencies, Composer conflicts, and PHP 8 failures can block builds. Keep it out of production dependencies and avoid adopting it unless you already run the exact Symfony, Behat, and Mink stack.
- How do I migrate away from kunstmaan/behat-bundle or reimplement its features?
- Do not adopt it as a dependency; treat it as a reference implementation. Read the three contexts, extract the behaviors, and port them into first-party context classes in your own test support namespace. Reimplement a screenshot capture hook, an Ajax wait polling jQuery.active or driver-level network idle, and a text-assertion wrapper; that is typically 100 to 200 lines of code. Then wire screenshot output into CI as a published artifact with a retention policy.