atoum-next/atoum-bundle
Symfony bundle for integrating atoum-next, the PHP unit testing framework, into Symfony applications. It provides bundle configuration, service wiring, and convenient test execution so teams can write and run atoum tests within a standard Symfony project.
Be clear about what this package is before you install it: atoum-next/atoum-bundle is the Symfony integration for the atoum testing framework. There is no Laravel service provider, no artisan command, and no Laravel test-case base class. For day-to-day Laravel work the thing you actually want is the underlying engine, atoum-next/atoum ^5.0 — the bundle only matters if you also maintain Symfony services in the same monorepo.
Minimal steps for a Laravel app:
composer require --dev atoum-next/atoum
Create .atoum.php at the project root and a bootstrap file that wires Laravel into atoum:
// .atoum.php
$runner->addTestsFromDirectory(__DIR__.'/tests/units');
// tests/bootstrap.php
require __DIR__.'/../vendor/autoload.php';
$app = require __DIR__.'/../bootstrap/app.php';
$app->make(Illuminate\Contracts\Console\Kernel::class)->bootstrap();
Run with vendor/bin/atoum -bf tests/bootstrap.php.
Look first at, in this order: the CHANGELOG (the release notes only link to it — the actual breaking-change list is not in the announcement, so read it before bumping), composer.json for the PHP/Symfony constraints, then the atoum-next/atoum docs for the assertion and mock API.
First real use case: keep PHPUnit/Pest for your HTTP and database feature tests, and reach for atoum on pure unit suites where its mock engine and per-assertion reporting are genuinely nicer.
Standalone-atoum-in-Laravel is the pattern most Laravel teams should adopt. Skip the bundle entirely, use atoum-next/atoum directly with a bootstrap that resolves the container, and inject what you need inside beforeTestMethod rather than relying on framework magic.
Symfony-side registration, if you do have Symfony apps alongside: add AtoumBundle to config/bundles.php and configure under the atoum: key in config/packages/. Note that 5.0 targets Symfony 7.4/8.0+, so this is a greenfield-only bundle for you — no 5.4/6.x apps.
Isolate the suites. Do not point atoum at the same directory as your PHPUnit tests; atoum's *::test* naming conventions and its own bootstrap will collide with phpunit.xml discovery. Keep tests/units/ (atoum) separate from tests/Feature/ (PHPUnit).
CI matrix should pin PHP 8.2/8.3/8.4 and run atoum as a second, independent job alongside php artisan test. Atoum failures exit non-zero, so a plain vendor/bin/atoum -bf tests/bootstrap.php step is enough. Add --coverage only if you're not already producing coverage from PHPUnit — running both collectors is wasted CI time.
Mocking collaborators is where atoum earns its place: $this->mock->array(...) / ->mock(SomeService::class) with ->call('method')->withArguments(...)->once() reads better than PHPUnit's expectation syntax for chained service calls. Use it for action/service units; use Laravel's facades fakes for anything touching the framework itself.
Container-aware tests need manual work: bind a test implementation of an interface into the booted app inside beforeTestMethod, then $this->container->make(...). Wrap this in a small base test class so it isn't repeated across every spec.
atoum-bundle → atoum-next/atoum-bundle means updating composer.json, any config/bundles.php entry, and — if you'd forked or extended it — the bundle class namespace and any service IDs. The old package name is effectively frozen; treat it as abandoned and check for advisories before leaving it in a composer.lock.composer why-not if resolution fails silently.atoum/atoum, you can end up with duplicate classes under the same atoum\ namespace. Run composer show | grep -i atoum after install and confirm exactly one provider is present.atoum-next/atoum is actively maintained, which is the real reason to care. Don't read it as Laravel compatibility.php artisan config:clear (or never cache config in CI) before atoum; the bootstrapped console kernel will happily serve a stale cached config otherwise, and you'll debug a phantom.-bf bootstrap runs before test discovery, but filesystem autoloading of test classes happens later — anything your specs need at parse time (constants, env vars) must be set in the bootstrap, not in beforeTestMethod.vendor/bin/atoum -bf tests/bootstrap.php --debug -v gives the full stack; -f <pattern> filters to one spec, which is the fastest loop. --no-teardown (where available) keeps the app booted between assertions when chasing container-state bugs..atoum.php using the standard atoum\ extension hooks — the fork does not rename the namespace, but confirm against vendor/atoum-next/atoum/classes before copying older snippets from blog posts.^5.0 deliberately and read the changelog diff on every minor — a rename release is the most likely time for undocumented config-key churn.RefreshDatabase, no actingAs, no parallel test runner, and no IDE integration via phpunit.xml. Budget for that before proposing atoum to a team that has only ever used Pest.How can I help you explore Laravel packages today?