CluPilotCloud/phpunit.xml

79 lines
4.5 KiB
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>
<!-- force=true so these override the dev .env that docker-compose injects
as real container env vars (otherwise tests use redis/mariadb). -->
<env name="APP_ENV" value="testing" force="true"/>
<!-- Pinned so the suite never depends on the operator's real hostnames:
route() builds URLs from APP_URL, and a deployment-specific
ADMIN_HOSTS would then 404 every admin route. Tests that exercise
the restriction set admin_access.hosts themselves. -->
<env name="APP_URL" value="http://localhost" force="true"/>
<env name="ADMIN_HOSTS" value="" force="true"/>
<!-- Fixed test key: storing a VPN config must be exercised, and a
random one would make a decryption failure irreproducible. -->
<env name="VPN_CONFIG_KEY" value="Y2x1cGlsb3QtdGVzdC1vbmx5LXZwbi1rZXktMzJieXQ=" force="true"/>
<!-- Blank so the suite never picks up the operator's real webhook secrets
from .env: with one set, every unsigned test payload is rejected as
an invalid signature. The tests that DO exercise verification set
the secret(s) themselves. _TEST is the live secret's sibling
(StripeWebhookSecret picks between them by operating mode) — same
variable class, same risk, so it gets the same treatment even
though no current test happens to need it. -->
<env name="STRIPE_WEBHOOK_SECRET" value="" force="true"/>
<env name="STRIPE_WEBHOOK_SECRET_TEST" value="" force="true"/>
<!-- Blank so the suite never reads this operator's REAL Hetzner DNS token
from .env. This one is load-bearing in a way the two above are not:
DnsTokenCheck proves write access by actually WRITING a TXT record
to the configured zone and deleting it again — a suite that fell
through to the real token would write to and delete from the real
clupilot.cloud zone on every test run. Every test that exercises
DnsTokenCheck uses Http::fake() and supplies its own candidate
token instead. -->
<env name="HETZNER_DNS_TOKEN" value="" force="true"/>
<!-- Pinned so the suite stops depending on the operator's .env. It did:
HostStepsTest asserted `fsn-01.node.clupilot.com` and passed only
because this server's .env carried the wrong zone. Correcting the
.env turned a green test red without a line of production code
changing — a test that reads the developer's machine proves
nothing about the code. The value is the one the code itself
defaults to. -->
<env name="CLUPILOT_DNS_ZONE" value="clupilot.cloud" force="true"/>
<!-- Die Datei-Domain wird beim Registrieren der Routen gelesen, nicht
beim Ausführen eines Tests. Ein config()->set() im Test kommt zu
spät: die Route existiert dann bereits oder eben nicht. -->
<env name="FILES_HOST" value="files.clupilot.test" force="true"/>
<env name="CLUPILOT_PLATFORM_ZONE" value="clupilot.com" force="true"/>
<env name="APP_MAINTENANCE_DRIVER" value="file"/>
<env name="BCRYPT_ROUNDS" value="4" force="true"/>
<env name="BROADCAST_CONNECTION" value="null" force="true"/>
<env name="CACHE_STORE" value="array" force="true"/>
<env name="DB_CONNECTION" value="sqlite" force="true"/>
<env name="DB_DATABASE" value=":memory:" force="true"/>
<env name="DB_URL" value="" force="true"/>
<env name="MAIL_MAILER" value="array" force="true"/>
<env name="QUEUE_CONNECTION" value="sync" force="true"/>
<env name="SESSION_DRIVER" value="array" force="true"/>
<env name="PULSE_ENABLED" value="false"/>
<env name="TELESCOPE_ENABLED" value="false"/>
<env name="NIGHTWATCH_ENABLED" value="false"/>
</php>
</phpunit>