<?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>
        <!--
            Ce qui coûte cher ici n'est pas la donnée — la base de test est un
            SQLite en mémoire de quelques dizaines de lignes — mais **le code**.
            Laravel, Filament et Livewire représentent plusieurs milliers de
            classes, et les compiler puis garder leurs tables de classes et leurs
            tableaux littéraux en mémoire coûte à lui seul près de 100 Mo, avant
            le premier test.

            Ce coût est payé ou non selon `opcache.enable_cli`. Quand opcache est
            actif en CLI, tout cela vit dans **son** segment partagé, qui ne
            compte pas dans `memory_limit`. Sinon, tout est sur le tas du
            processus. Mesuré sur cette suite :

                                opcache CLI actif   inactif
                PHP 8.3              33 Mo           116 Mo
                PHP 8.4              36 Mo           118 Mo

            La version de PHP n'y est donc pour presque rien (2 à 3 Mo) : c'est
            `opcache.enable_cli` qui fait les 80 Mo d'écart. Le MAMP 8.3 local
            l'active, le PHP 8.4 du PATH non — d'où une suite verte sur une
            version et morte sur l'autre, pour une raison sans rapport avec le
            code.

            512 Mo met la suite à l'abri des deux configurations. Sans ça,
            l'échec tombe sur le test en cours au moment où le tas s'épuise,
            jamais sur un coupable — un diagnostic parfaitement trompeur.
        -->
        <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="CACHE_STORE" value="array"/>
        <env name="DB_CONNECTION" value="sqlite"/>
        <env name="DB_DATABASE" value=":memory:"/>
        <env name="MAIL_MAILER" value="array"/>
        <env name="PULSE_ENABLED" value="false"/>
        <env name="QUEUE_CONNECTION" value="sync"/>
        <env name="SENTRY_LARAVEL_DSN" value=""/>
        <env name="SESSION_DRIVER" value="array"/>
        <env name="TELESCOPE_ENABLED" value="false"/>
        <!-- Même raisonnement que SENTRY_LARAVEL_DSN ci-dessus : la suite ne
             doit jamais dépendre de ce qui se trouve dans le `.env` local
             (JOS-147) — sans ce vidage explicite, poser une vraie clé
             Turnstile en local fait échouer toute la suite Guest, qui
             suppose le captcha désactivé par défaut. -->
        <env name="TURNSTILE_SITE_KEY" value=""/>
        <env name="TURNSTILE_SECRET_KEY" value=""/>
    </php>
</phpunit>
