- How do I install zalas/phpunit-globals in a Laravel project?
- Install it as a dev dependency with composer require --dev zalas/phpunit-globals. Then add the extension to the <extensions> section of your phpunit.xml. Because it is a test-only package, it should never be required in the production dependency set. If your project still uses the older PHPUnit 9 XML schema, upgrade the phpunit.xml schema first, since that schema has no <extensions> block.
- Does zalas/phpunit-globals work with PHPUnit 9?
- No. The package plugs into PHPUnit's supported extension API, which does not exist in PHPUnit 9, so projects pinned to PHPUnit 9 are blocked. You need PHPUnit 10 or newer, and PHP 8.1 or later because the package relies on PHP attributes. Check the PHPUnit version in composer.json and in your Laravel skeleton's phpunit.xml before adopting it. If your CI pins an older PHPUnit for coverage runs, that job will need updating too.
- How do I set a global variable for a single PHPUnit test?
- Add a #[GlobalVar('key', 'value')] attribute to the test method instead of mutating $GLOBALS, $_SERVER, or $_ENV by hand in setUp(). Multiple attributes can be stacked on the same method when a test needs more than one global. Attributes placed on the test class apply to every test in that class. This makes global-state dependencies explicit and greppable rather than hidden inside lifecycle hooks.
- Are the global variables restored or just unset after each test?
- The package performs automatic cleanup after each test so values do not leak into other tests. Whether a pre-existing value is restored to its original value or simply cleared is the key semantic to verify for your PHPUnit version, so write one test that reads the global before and after and assert the result you expect. Getting this wrong can hide ordering bugs between tests that share a process. Confirm the behaviour during your pilot before rolling the attribute out broadly.
- Does zalas/phpunit-globals work with process isolation or Paratest?
- Treat this as unconfirmed. Values set in the parent process do not exist in a forked process, so tests marked @runInSeparateProcess or run under a parallel runner such as Paratest may see the global as missing. Scope adoption to non-isolated tests until you have verified behaviour in your own suite. If you need isolation, set the globals inside the child process instead of via attributes.
- Does it work with Pest tests?
- Pest compatibility is not guaranteed. Pest tests are closures, so class-level attributes may not apply the way they do on a PHPUnit test class, and the global may never be set. If you are migrating a mixed suite, test Pest files separately before relying on the attribute. Pure PHPUnit test classes are the safe, well-supported path.
- What happens if I forget to register the extension in phpunit.xml?
- The attributes become inert and nothing fails. Tests still pass while the global is silently unset, which produces false confidence rather than a red build. This is the sharpest failure mode of the package. To protect against it, assert inside a smoke test that the global actually contains the expected value, and review phpunit.xml as part of code review whenever the attribute is introduced.
- Can it set a global that must exist before the Laravel application boots?
- Probably not. Attributes are applied during test execution, which is likely too late for superglobals read while bootstrap/app.php or a service provider is being resolved. If your code reads $_SERVER or an environment value during boot, set it in phpunit.xml <php><env> or a bootstrap file instead. Keep attribute usage limited to values that are only read inside the test body or the code it exercises.
- Is zalas/phpunit-globals safe to use in a production Laravel application?
- It has no production surface because it is a dev-only PHPUnit extension with no runtime coupling to application code. It does not touch Laravel's container, config, or bootstrapping. The realistic risk is behavioural rather than structural, so the worst case is forking the handful of classes involved. Run composer audit and pin the lockfile as you would for any other dev dependency.
- When should I use this instead of Laravel's Config::set or dependency injection?
- Use it only where the code under test genuinely reads $GLOBALS or a superglobal and refactoring is not practical, such as legacy or third-party code. When a test can inject config through the container or Config::set(), that remains the better answer. Treat the package as a complement to proper dependency injection, not a licence to add new global state. Start read-only by inventorying existing superglobal mutations, then pilot on one or two test classes with the highest density of manual global setup.