Automated Testing
Cloud emulators are most powerful when they are driven by automation. Null Autos is designed so that anything you can do by hand, you can do in a pipeline: launching devices, driving vehicle state, running test suites, and tearing everything down.
The pattern
A typical automated test job:
- Provisions one or more emulators from a known snapshot.
- Installs the application under test over ADB.
- Sets vehicle state through VHAL to exercise automotive-specific scenarios (driving, parked, charging, climate, and so on).
- Runs UI, integration, or system tests against the device.
- Collects logs and results.
- Tears down the emulators to free capacity.
What makes it automotive-aware
Unlike generic device farms, Null Autos exposes the Vehicle HAL, so your tests can put the device into realistic vehicle conditions and assert how your software responds. For example, you can verify that an IVI app behaves correctly at speed, on battery, or with a door open. See Working with VHAL.
Scaling out
Because emulators are created on demand through the API, you can launch many in parallel to shard a test suite or cover multiple device configurations at once, then release them when the run completes. Per-user limits keep capacity fair, so coordinate larger runs with your tenant admin.
How to drive it
| From | Use |
|---|---|
| CLI | nullctl create emulator, nullctl adb connect, nullctl delete emulator in scripts |
| API | POST /api/v1/emulators, ADB proxy, VHAL gRPC, DELETE /api/v1/emulators/{id} |
| GitLab CI | Job-token auth means no secrets to manage in pipelines |
See CI/CD integration for a worked pipeline example.