phpunit.xml

<?xml version="1.0" encoding="UTF-8"?>
<phpunit xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:noNamespaceSchemaLocation="vendor/phpunit/phpunit/phpunit.xsd"
         bootstrap="vendor/autoload.php"
         colors="true"
>
    <testsuites>
        <testsuite name="Unit">
            <directory>tests/Unit</directory>
        </testsuite>
        <testsuite name="Feature">
            <directory>tests/Feature</directory>
        </testsuite>
    </testsuites>
    <source>
        <include>
            <directory>app</directory>
        </include>
    </source>
    <php>
        <!--
            🔴 The suite peaks at 126 MB against PHP's 128 MB default, and nothing here said so.

            Measured rather than guessed, because the symptom looked like a leak: it failed every
            other run with "Allowed memory size exhausted" in PhpEngine, which is a compiled view
            being included. Three points settle it — 70 tests 54 MB, 433 tests 126 MB, 503 tests
            126 MB. It PLATEAUS: between 433 and 503 the figure does not move, so nothing is
            accumulating per test. What costs the memory is Laravel booted and views rendered, and
            the gap between 126 and 128 is what a run needs when it also has to compile them.

            ⚠ Declared here rather than left to each machine's php.ini: the limit that decides
            whether the suite passes must not be a property of the laptop it runs on. A CI with a
            lower default would have failed on a codebase everyone else called green.
        -->
        <ini name="memory_limit" value="512M"/>
        <env name="APP_ENV" value="testing"/>
        <env name="APP_MAINTENANCE_DRIVER" value="file"/>
        <env name="BCRYPT_ROUNDS" value="4"/>
        <env name="BROADCAST_CONNECTION" value="null"/>
        <env name="CACHE_STORE" value="array"/>
        <!--
            🔴 The suite runs on the engine production runs on. It used to run on SQLite in memory,
            which was faster (71 s against 86 s) and hid a whole class of defects: a `having()`
            without `groupBy`, a `firstOrCreate` on a date column, a packet-size limit, and a
            migration whose `down()` could not run backwards on MySQL — all green here, all broken
            there. Fifteen seconds is not worth a category of failure no test can see.

            ⚠ A SEPARATE database, never the development one: `RefreshDatabase` starts by wiping
            whatever it is pointed at.

            ⚠ These are defaults, not a requirement: PHPUnit does not overwrite a variable the
            environment already carries, so real env vars win. Anyone without this container can
            still run the suite elsewhere — the code stays portable, including on SQLite:
              $env:DB_CONNECTION='sqlite'; $env:DB_DATABASE=':memory:'; php artisan test
        -->
        <env name="DB_CONNECTION" value="mysql"/>
        <env name="DB_HOST" value="127.0.0.1"/>
        <env name="DB_PORT" value="33306"/>
        <env name="DB_DATABASE" value="unitygametranslator_test"/>
        <env name="DB_USERNAME" value="root"/>
        <env name="DB_PASSWORD" value="local-dev-2026"/>
        <env name="MAIL_MAILER" value="array"/>
        <env name="QUEUE_CONNECTION" value="sync"/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="PULSE_ENABLED" value="false"/>
        <env name="TELESCOPE_ENABLED" value="false"/>
        <env name="NIGHTWATCH_ENABLED" value="false"/>
    </php>
</phpunit>