JLR - OneApp & Home Charging Units
- Year
- 2025
- Role
- Software Engineer in Test (SEIT)
- Stack
- Gherkin
- Robot Framework
- JavaScript
- TypeScript
- Python
The problem
OneApp and the Home Charging Units both needed functional coverage of their API services before release, and the charging units are physical hardware, so their API couldn't be exercised from a laptop.
The approach
The framework (Gherkin scenarios driving Robot Framework) was already in place when I joined, and so was the standard a feature had to clear: success paths, error responses, and the surrounding API calls it depended on. My job was coverage against an existing bar rather than defining one. Where the role earned its place was the piece of work that didn't clear it: thin error handling meant it went back rather than out, against a release date.
Testing against hardware
The Home Charging Units could only be tested against a physical rig in the office, and standing it up took more than wiring: someone who knew the hardware had to be there in person, plus test credentials and test accounts that could present as a unit genuinely in use. For a while it was the only thing holding the team's tests up, so rather than wait I wrote the tests against the expected API behaviour in parallel, ready to plug in the day the rig came up. Being across several teams, the rest of the time went where nothing was blocked.
What the tests found first
They took some working in. Most of that was debugging why the test accounts wouldn't connect, and chasing it surfaced something missing from the rig itself: without an extra component simulating a car linked and charging, the one scenario the product exists for couldn't be exercised at all.
The outcome
I rolled off the engagement before release. Both products went on to launch.