Aktionen & Tests

Vieles in einem Projekt sind immer dieselben paar Befehle: Abhängigkeiten installieren, Migrationen laufen lassen, einen Cache leeren, die Tests starten. Dafür hat Envoryx zwei Bereiche, damit du nicht jedes Mal ein Terminal aufmachen musst.

Aktionen

Der Bereich Aktionen führt vordefinierte Befehle im passenden Runtime-Container aus, als Projektbesitzer, und zeigt dir die Ausgabe live. Die Liste ist mit Absicht fest: Dein Browser schickt nur die ID einer Aktion, nie eine Befehlszeile, da lässt sich also nichts einschmuggeln. In der Liste stehen die Aktionen aller Runtimes, die das Projekt hat, anklicken kannst du aber nur die, deren Dateien da sind: composer install braucht eine composer.json, rails db:migrate ein bin/rails und so weiter. Die anderen bleiben ausgegraut, mit dem Grund daneben, ein Symfony-Projekt zeigt die Artisan-Aktionen also mit artisan wurde im Projekt nicht gefunden. pnpm und Yarn brauchen ihr Lockfile, außer in einem Projekt, dessen Node.js-Runtime auf genau diesen Paketmanager eingestellt ist: Dort reicht die package.json, damit ein frisches Projekt seine erste Installation laufen lassen kann. Alles, was etwas kaputtmachen kann, fragt vorher nach.

Das steht zur Auswahl:

Gruppe	Aktionen
PHP	php -v, php -m
Composer	composer install, composer update, composer dump-autoload
Artisan (Laravel)	migrate, migrate:fresh --seed, db:seed, key:generate, storage:link, cache:clear, optimize:clear
Symfony	console cache:clear, console doctrine:migrations:migrate
CMS	drush site:install, drush cache:rebuild (Drupal), typo3 setup, Shopware system:install --basic-setup, craft install
Node.js	node -v; npm install, ci, run build; pnpm install, run build; yarn install, build
Python	python --version, python -m venv .venv; pip install -r requirements.txt, freeze; uv sync, lock
Django	manage.py migrate, makemigrations, collectstatic, check, flush
Go	go version, go build ./..., go vet ./..., gofmt -l ., go mod tidy, go mod download, go generate ./...
Ruby	ruby --version, rubocop; Bundler install, update, outdated
Rails	db:prepare, db:migrate, db:rollback, db:seed, routes, assets:precompile, tmp:clear, about
Java	java -version; Maven package, clean, dependency:tree, versions:display-dependency-updates; Gradle build, clean, dependencies, tasks
.NET	dotnet --info, restore, build, clean, format, list package --outdated; dotnet ef database update, dotnet ef migrations list

Die CMS-Installer für Drupal, TYPO3, Shopware und Craft richten die Seite gegen die Projektdatenbank ein. Drupal, TYPO3 und Craft geben am Ende das erzeugte Admin-Passwort aus, behalte die Ausgabe also im Auge. Der Shopware-Installer legt immer den Login admin mit dem Passwort shopware an, den du danach besser im Admin änderst. Für WordPress gibt es hier keine Aktion; sein Installer läuft im Browser, sobald du die Seite öffnest.

Dieselben Aktionen kannst du auch aus einem Skript starten oder von einem Assistenten erledigen lassen:

envoryx project run shop                      # die Aktionen des Projekts auflisten
envoryx project run shop artisan:migrate      # eine ausführen, mit Live-Ausgabe

Steht das, was du brauchst, nicht in der Liste, nimm das Terminal oder envoryx project exec.

Tests

Der Bereich Tests sucht im Projektverzeichnis nach Test-Suites und führt sie im Runtime-Container aus, auch hier mit Live-Ausgabe. Diese erkennt er:

Suite	Erkannt an	Filter
Pest	vendor/bin/pest (PHPUnit steht dann nicht extra da, Pest führt diese Tests mit aus)	--filter
PHPUnit	vendor/bin/phpunit oder bin/phpunit (Symfonys Bridge), wenn es kein Pest gibt	--filter
npm-Skripte	test und test:* in der package.json (yarn oder pnpm, wenn deren Lockfile da ist)	wird ans Skript weitergereicht
Playwright	playwright.config.*	--grep
Cypress	cypress.config.*	--spec
pytest	pytest.ini, conftest.py, pytest in der pyproject.toml ([tool.pytest], die Abhängigkeiten, uvs [dependency-groups]), in der uv.lock oder in den Requirements	-k
Django	manage.py	Test-Label
Go	go.mod - go test ./... über gotestsum	-run
RSpec	ein spec/-Verzeichnis und rspec in der Gemfile.lock	-e (Name des Beispiels)
Rails	bin/rails und ein test/-Verzeichnis - bin/rails test	-n (Testname oder /regexp/)
Maven, Gradle	pom.xml - mvn test, build.gradle - gradle test	-Dtest, --tests
.NET	ein Testprojekt (xUnit, NUnit, MSTest, TUnit oder das Test-SDK) - dotnet test	--filter

Verlangt die composer.json eine Test-Suite, die noch nicht installiert ist, taucht sie trotzdem auf, mit dem Hinweis, erst composer install laufen zu lassen. Was du als Filter eintippst, geht als ein einziges Argument an den Runner, nie durch eine Shell.

Nach einem Lauf willst du wissen, was kaputt ist. PHPUnit, Pest, Playwright, Cypress, pytest, Go, RSpec, Maven und Gradle schreiben einen JUnit-Report (RSpec braucht dafür rspec_junit_formatter im Bundle), dotnet test einen TRX-Report, und Envoryx zeigt dir die Zahlen und jeden fehlgeschlagenen Test mit seiner Meldung, dazu Datei und Zeile, wo der Runner sie nennt. Go nennt nur den Dateinamen, nicht das Paketverzeichnis davor. Die Reports von Maven und Gradle enthalten die Meldung, aber weder Datei noch Zeile; da schaust du in die Details oder die Ausgabe. rails test, RSpec ohne den Formatter, Djangos manage.py test und Vitest oder Jest hinter einem Testskript der package.json schreiben keinen Report, Envoryx liest Zusammenfassung und Fehler aber aus der Ausgabe und zeigt sie genauso an. Nur bei anderen Skripten entscheidet allein der Exit-Code, ob es geklappt hat. Die letzten 50 Läufe bleiben unter Letzte Läufe stehen, jeder mit seiner Ausgabe, damit du auch später noch nachlesen kannst, was ein älterer Lauf ausgegeben hat. Brichst du einen Lauf ab oder schließt den Tab, wird er gestoppt.

Tests bekommen eine eigene Datenbank

Eine Testsuite, die das Schema zurücksetzt oder Fixtures lädt, tut das mit der Datenbank, auf die sie zeigt, und die Variablen, die Envoryx einspeist, zeigen auf deine Entwicklungsdatenbank. Laravels RefreshDatabase würde also munter migrate:fresh auf deinen Daten ausführen. Deshalb gehen die Runner, die mit einer Datenbank arbeiten, stattdessen auf <datenbank>_test auf dem Datenbankserver des Projekts.

Bei PHPUnit und Pest richtet Envoryx DB_DATABASE, DB_URL und DATABASE_URL dorthin. Die übrigen <env>-Einträge der phpunit.xml (oder der phpunit.xml.dist, wenn es keine phpunit.xml gibt) bekommt der Lauf so, wie sie dastehen. PHPUnit selbst setzt nur, was in der Umgebung noch fehlt, und im Container ist schon alles gesetzt, dein eigenes QUEUE_CONNECTION=redis genauso wie die MAIL_*-Variablen für Mailpit. Ohne das landete ein Job aus einem Test in deiner Entwicklungs-Queue, der Dev-Worker schriebe in deine Entwicklungsdatenbank, und die Mail käme in deinem Mailpit-Postfach an. Nur die Datenbank-Einträge zählen nicht, außer die Tests laufen auf SQLite (DB_CONNECTION=sqlite in der phpunit.xml). Das Doctrine-Recipe von Symfony hängt _test selbst an (dbname_suffix unter when@test in config/packages/doctrine.yaml); steht diese Zeile da, bleibt DATABASE_URL, wie sie ist, und beide Wege enden bei derselben Datenbank. RSpec und rails test laufen in der Test-Umgebung, weil Active Record DATABASE_URL in jede Umgebung übernimmt. Die Läufe von Java und .NET schreiben ihre Datenbank-URLs und den Connection-String genauso um, siehe die Seiten zu Java und .NET. Djangos Runner und pytest-django (pytest neben einer manage.py) nennen ihre Testdatenbank selbst test_<datenbank>.

In jedem Fall legt Envoryx die Testdatenbank vor dem Lauf an, als Administrator, weil der Projekt-Login von MySQL und MariaDB keine Datenbanken anlegen darf. Was hineinkommt, ist Sache der Tests: Laravels RefreshDatabase migriert selbst, Rails lädt sein Schema, und bei Symfony führst du einmal bin/console doctrine:schema:create --env=test aus. Ein Projekt mit SQLite behält seine Datei, und MongoDB, npm-Skripte, Playwright, Cypress, reines pytest und go test laufen mit den Projektvariablen, wie sie sind.

Playwright und Cypress brauchen Browser und Systembibliotheken, die im Node-Image nicht drin sind. Browser-Tests sind deshalb meist auf einem Rechner oder CI-Runner besser aufgehoben, der sie mitbringt.