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"
         cacheDirectory=".phpunit.cache">
    <testsuites>
        <testsuite name="Unit">
            <directory>tests/Unit</directory>
            <directory>tests/Helpers</directory>
            <!-- Modules/Auth/tests/Unit is covered by the dedicated
                 AuthUnit testsuite below; including it here too
                 emits "Cannot add file ... as it was already
                 added to test suite" WARN noise on every pest
                 run. -->
            <directory>Modules/Anomaly/tests/Unit</directory>
            <directory>Modules/Core/tests/Unit</directory>
            <directory>Modules/Goals/tests/Unit</directory>
            <directory>Modules/Ledger/tests/Unit</directory>
            <directory>Modules/Pots/tests/Unit</directory>
            <directory>Modules/Ingestion/tests/Unit</directory>
            <directory>Modules/Import/tests/Unit</directory>
            <directory>Modules/Categorization/tests/Unit</directory>
            <directory>Modules/Community/tests/Unit</directory>
            <directory>Modules/Counterparties/tests/Unit</directory>
            <!-- Modules/DriftAlerts/tests/Unit is covered by the
                 dedicated DriftAlerts testsuite (which spans
                 tests/, not just Unit) below. -->
            <directory>Modules/Transfers/tests/Unit</directory>
            <directory>Modules/Receipts/tests/Unit</directory>
            <directory>Modules/Recurring/tests/Unit</directory>
            <directory>Modules/Desktop/tests/Unit</directory>
            <directory>Modules/DevMode/tests/Unit</directory>
            <directory>Modules/Onboarding/tests/Unit</directory>
            <directory>Modules/Budgets/tests/Unit</directory>
            <directory>Modules/Calendar/tests/Unit</directory>
            <directory>Modules/Tax/tests/Unit</directory>
            <directory>Modules/Search/tests/Unit</directory>
            <directory>Modules/Notifications/tests/Unit</directory>
        </testsuite>
        <testsuite name="Feature">
            <directory>tests/Feature</directory>
            <directory>Modules/Anomaly/tests/Feature</directory>
            <directory>Modules/Goals/tests/Feature</directory>
            <directory>Modules/Pots/tests/Feature</directory>
            <directory>Modules/Ingestion/tests/Feature</directory>
            <directory>Modules/Categorization/tests/Feature</directory>
            <directory>Modules/Community/tests/Feature</directory>
            <directory>Modules/Counterparties/tests/Feature</directory>
            <!-- Modules/DriftAlerts/tests/Feature is covered by the
                 dedicated DriftAlerts testsuite below; including it
                 here too triggers the same "Cannot add file …
                 already added" testRunnerTriggeredPhpunitWarning
                 noise that the Auth exclusion above prevents, which
                 in turn tips the Pest exit code to 1 on otherwise-
                 passing runs. -->
            <directory>Modules/Transfers/tests/Feature</directory>
            <directory>Modules/Receipts/tests/Feature</directory>
            <directory>Modules/Recurring/tests/Feature</directory>
            <directory>Modules/Desktop/tests/Feature</directory>
            <directory>Modules/DevMode/tests/Feature</directory>
            <directory>Modules/Onboarding/tests/Feature</directory>
            <directory>Modules/Budgets/tests/Feature</directory>
            <directory>Modules/CashBook/tests/Feature</directory>
            <directory>Modules/Calendar/tests/Feature</directory>
            <directory>Modules/Tax/tests/Feature</directory>
            <directory>Modules/Search/tests/Feature</directory>
            <directory>Modules/Shell/tests/Feature</directory>
            <directory>Modules/Notifications/tests/Feature</directory>
            <directory>Modules/Position/tests/Feature</directory>
        </testsuite>
        <!-- Lifted out of the generic Feature suite because a testsuite is the
             smallest thing the shard resolver can move, and Feature was one
             indivisible block of 945 files: the longest shard could never go
             below it however the weights were set. These three are its heaviest
             members, and splitting them follows what the file already does for
             every other heavy module — Auth, EmailScan, OpenBanking and Chains
             all have their own Feature suite for the same reason.

             Each directory is claimed by exactly one suite, which is what keeps
             the "Cannot add file ... as it was already added" warning away; a
             run carrying that warning exits 1 with nothing failing. Verified by
             running the three together: 1431 passed, no warning. -->
        <testsuite name="CoreFeature">
            <directory suffix="Test.php">./Modules/Core/tests/Feature</directory>
        </testsuite>
        <testsuite name="ImportFeature">
            <directory suffix="Test.php">./Modules/Import/tests/Feature</directory>
        </testsuite>
        <testsuite name="LedgerFeature">
            <directory suffix="Test.php">./Modules/Ledger/tests/Feature</directory>
        </testsuite>
        <testsuite name="Contracts">
            <directory>tests/Contracts</directory>
        </testsuite>
        <testsuite name="Snapshot">
            <directory>tests/Snapshot</directory>
            <directory>Modules/Import/tests/Snapshot</directory>
        </testsuite>
        <testsuite name="ChainsUnit">
            <directory suffix="Test.php">./Modules/Chains/tests/Unit</directory>
        </testsuite>
        <testsuite name="ChainsFeature">
            <directory suffix="Test.php">./Modules/Chains/tests/Feature</directory>
        </testsuite>
        <testsuite name="ChainsContracts">
            <directory suffix="Test.php">./Modules/Chains/tests/Contracts</directory>
        </testsuite>
        <testsuite name="DriftAlerts">
            <directory suffix="Test.php">./Modules/DriftAlerts/tests</directory>
        </testsuite>
        <testsuite name="Forecasting">
            <directory suffix="Test.php">./Modules/Forecasting/tests</directory>
        </testsuite>
        <testsuite name="AuthUnit">
            <directory suffix="Test.php">./Modules/Auth/tests/Unit</directory>
        </testsuite>
        <testsuite name="AuthFeature">
            <directory suffix="Test.php">./Modules/Auth/tests/Feature</directory>
        </testsuite>
        <testsuite name="EmailScanUnit">
            <directory suffix="Test.php">./Modules/EmailScan/tests/Unit</directory>
        </testsuite>
        <testsuite name="EmailScanFeature">
            <directory suffix="Test.php">./Modules/EmailScan/tests/Feature</directory>
        </testsuite>
        <testsuite name="EmailScanIntegration">
            <directory suffix="Test.php">./Modules/EmailScan/tests/Integration</directory>
        </testsuite>
        <!-- The only Integration tree without a testsuite, so its two smoke
             tests ran nowhere: not in CI, not locally, not even to be skipped.
             They are tagged `integration` to be excluded on a host without
             poppler, which is a different thing from never being collected.
             Every job that runs tests installs poppler-utils. -->
        <testsuite name="IngestionIntegration">
            <directory suffix="Test.php">./Modules/Ingestion/tests/Integration</directory>
        </testsuite>
        <testsuite name="OpenBankingUnit">
            <directory suffix="Test.php">./Modules/OpenBanking/tests/Unit</directory>
        </testsuite>
        <testsuite name="OpenBankingFeature">
            <directory suffix="Test.php">./Modules/OpenBanking/tests/Feature</directory>
        </testsuite>
        <testsuite name="OpenBankingContracts">
            <directory suffix="Test.php">./Modules/OpenBanking/tests/Contracts</directory>
        </testsuite>
        <testsuite name="OpenBankingIntegration">
            <directory suffix="Test.php">./Modules/OpenBanking/tests/Integration</directory>
        </testsuite>
        <testsuite name="ReceiptsContracts">
            <directory suffix="Test.php">./Modules/Receipts/tests/Contracts</directory>
        </testsuite>
        <testsuite name="FXUnit">
            <directory suffix="Test.php">./Modules/FX/tests/Unit</directory>
        </testsuite>
        <testsuite name="FXFeature">
            <directory suffix="Test.php">./Modules/FX/tests/Feature</directory>
        </testsuite>
        <testsuite name="Sync">
            <directory suffix="Test.php">./Modules/Sync/tests/Arch</directory>
            <directory suffix="Test.php">./Modules/Sync/tests/Feature</directory>
            <directory suffix="Test.php">./Modules/Sync/tests/Unit</directory>
        </testsuite>
        <!-- Mobile is the composite of these two directories. It used to sit
             alongside MobileUnit and MobileFeature, which listed the same two
             directories again, and PHPUnit refuses to add a file to a second
             suite: every one of the 23 Mobile feature tests raised "Cannot add
             file ... as it was already added", and a run carrying those
             warnings exits 1 with zero failing tests. Only a run that loads
             more than one suite can trip it, so every single-suite run was
             green and the full suite was red for no visible reason.
             `vendor/bin/pest Modules/Mobile/tests/Unit` still runs a subset. -->
        <testsuite name="Mobile">
            <directory suffix="Test.php">./Modules/Mobile/tests/Feature</directory>
            <directory suffix="Test.php">./Modules/Mobile/tests/Unit</directory>
        </testsuite>
        <testsuite name="MigrationUnit">
            <directory suffix="Test.php">./Modules/Migration/tests/Unit</directory>
        </testsuite>
        <testsuite name="MigrationFeature">
            <directory suffix="Test.php">./Modules/Migration/tests/Feature</directory>
        </testsuite>
        <testsuite name="MigrationContracts">
            <directory suffix="Test.php">./Modules/Migration/tests/Contracts</directory>
        </testsuite>
        <testsuite name="Reports Unit">
            <directory suffix="Test.php">./Modules/Reports/tests/Unit</directory>
        </testsuite>
        <testsuite name="Reports Feature">
            <directory suffix="Test.php">./Modules/Reports/tests/Feature</directory>
        </testsuite>
        <!-- Modules/EmailScan/tests/Contracts and Modules/Reports/tests/Contracts
             hold a .gitkeep and nothing else. A testsuite that matches no file
             makes a single-testsuite run exit 1 on "No tests found", which the
             setup guide tells developers to do. An earlier fix
             tracked the empty directory to stop the 1-error; the directory was
             never the problem. The suites come back with their first test. -->
    </testsuites>
    <php>
        <!-- The architecture tests parse every file under Modules/ and app/ with
             php-parser and hold the ASTs for the duration of the assertion, so
             peak memory tracks the size of the codebase rather than the size of
             any one test. Thirty-four modules outgrew the previous 1G ceiling,
             which failed the whole suite during construction rather than as a
             test failure. Headroom, not a measured peak: a value tuned to the
             current tree would need re-tuning at the next module. -->
        <ini name="memory_limit" value="4G"/>
        <env name="APP_ENV" value="testing"/>
        <env name="APP_KEY" value="base64:vQc4qXIjcS1Wt2kPQzGpL3yvqW6CrLqzqkEYqFqW7DA="/>
        <!-- force="true" so asset()/route() URLs in rendered-HTML snapshots are
             deterministic (https://beatrax.test) regardless of a local .env
             APP_URL pointed at the dev server. -->
        <env name="APP_URL" value="https://beatrax.test" force="true"/>
        <env name="APP_MAINTENANCE_DRIVER" value="file"/>
        <!-- Forced: without it the suite ran at whatever the developer's .env said
             and at UTC on the runner, so a day-boundary assertion could pass on
             one and fail on the other. It is also what tells InstallTimezone the
             frame was chosen rather than detected. -->
        <env name="APP_TIMEZONE" value="UTC" force="true"/>
        <env name="BCRYPT_ROUNDS" value="4"/>
        <!--
            force="true" so the suite always runs with the Dev Console off,
            even when a local .env sets BEATRAX_DEV_MODE=true for the dev
            server. Without it, dev-mode-gated behaviour (e.g. Horizon route
            registration) would leak into the test run from the developer's
            environment.
        -->
        <env name="BEATRAX_DEV_MODE" value="false" force="true"/>
        <env name="CACHE_STORE" value="array"/>
        <!--
            force="true" so the isolated in-memory test connection wins even
            when a real DB_CONNECTION env var is present (the Docker dev
            toolchain exports DB_CONNECTION=sqlite for ad-hoc artisan use).
            Without it, the suite would silently run against the WAL-configured
            on-disk `sqlite` connection and lose per-test isolation.
        -->
        <env name="DB_CONNECTION" value="sqlite_testing" force="true"/>
        <!--
            force="true" so the suite never writes to the developer's own log.
            A local .env carries LOG_CHANNEL=stack / LOG_STACK=single /
            LOG_LEVEL=debug, and nothing here overrode it: every run appended
            to storage/logs/laravel.log, the same file the Dev Console tailer
            reads. One tree reached half a gigabyte that way — mostly
            deliberately-provoked failure paths, which drowned the real
            entries the tailer exists to surface.

            `null` and not a second file: a test asserting on a log line does
            so through an injected LoggerInterface or Log::spy(), never by
            reading from disk, so a file here would accumulate output nothing
            ever reads. LOG_STACK is pinned too — leaving it would let the
            stack driver keep resolving `single` underneath.
        -->
        <env name="LOG_CHANNEL" value="null" force="true"/>
        <env name="LOG_STACK" value="null" force="true"/>
        <env name="LOG_DEPRECATIONS_CHANNEL" value="null" force="true"/>
        <env name="MAIL_MAILER" value="array"/>
        <env name="PULSE_ENABLED" value="false"/>
        <env name="QUEUE_CONNECTION" value="sync"/>
        <env name="SESSION_DRIVER" value="database"/>
        <env name="TELESCOPE_ENABLED" value="false"/>
    </php>

    <!-- Without this, a coverage run warns "No filter is configured, code
         coverage will not be processed", writes an empty report, and exits 1
         with every test passing — the same shape of failure as a file claimed
         by two testsuites. The clover report the coverage workflow hands to
         SonarCloud was empty for exactly this reason.

         app/ and Modules/ are where the code under test lives. Migrations are
         schema, replayed by every test and meaningless as a coverage figure;
         config/, routes/ and database/ stay in sonar.sources so the analyser
         still reads them, and sit in sonar.coverage.exclusions so they do not
         count against the number. -->
    <source>
        <include>
            <directory suffix=".php">app</directory>
            <directory suffix=".php">Modules</directory>
        </include>
        <exclude>
            <directory suffix=".php">Modules/*/Database/Migrations</directory>
            <directory suffix=".php">Modules/*/tests</directory>
            <!-- A .blade.php file matches the .php suffix above, so the clover
                 report carried 24658 template lines that pcov can never mark
                 as covered: Blade compiles to storage/framework/views/ and the
                 coverage lands on the compiled file, never on this path. They
                 are rendered and asserted on by the suite; they simply cannot
                 be measured here. -->
            <directory suffix=".blade.php">Modules/*/Resources/views</directory>
            <directory suffix=".blade.php">resources/views</directory>
        </exclude>
    </source>
</phpunit>