The Testing view lets you build, run, and inspect your project's own app instances directly from AITM — separately from whatever pipeline tasks are running.
Testing
Build & Start/Stop
Trigger a build of your project, then start or stop a running instance of it on its own dedicated port — independent of the isolated instances the pipeline spins up for E2E testing during a task.
Live status and terminal output
See at a glance whether your instance is running, building, or stopped, and stream its terminal/console output live — useful for confirming a build succeeded or diagnosing why it didn't.
Stopping a running test run
You can stop a long-running unit test suite at any time directly from the Testing view, without waiting for it to finish. If the AITM server is restarted while a test run is in progress, the run is interrupted safely — it won't be left stuck in a "running" state on the next startup; the server detects and clears it.
Combined CPU/RAM budget for tests
Unit tests and E2E tests share one overall CPU and memory budget that automatically adapts to the size of the server AITM runs on. Tests run sequentially so their combined resource use never overloads the host — this protects against crashes caused by running multiple test workloads at once.
E2E verdict history
Every end-to-end test run recorded against this project is kept here, with its verdict (pass, feature bug, environment error, etc.) and a timeline you can scroll back through to see how test health has trended over time.
Bug indicator dropdown
The bug indicator dropdown in the top bar shows at most the 10 most recent bugs, keeping it fast and readable even on projects with a long bug history. It always shows an Open Bug Section link — even when the recent-items list is empty — so the dropdown never dead-ends; you're always one click away from the full bug list regardless of how many recent items exist.
Tips
- Keep a project's own instance stopped when you're not actively testing it — it frees the port for the pipeline's isolated E2E instances.
- Check the E2E verdict history before re-running a full test suite — a past environment error might explain a failure that isn't actually a code bug.