Optimizing Testing for Server-Driven Mobile Development at Strava
Article Summary
Strava's Android team hit a wall: testing server-driven UI meant wrestling with Charles Proxy crashes, EOF errors, and 3-4 minute build times. An intern decided to fix it.
Xin Yi Chen, a UC Berkeley intern on Strava's Multisport team, built an internal testing tool to streamline development of their server-driven mobile architecture. The article walks through the problem, refactoring challenges, and solution that cut testing friction significantly.
Key Takeaways
- Server-driven UI uses reusable view modules (atoms) across different screens (molecules)
- Charles Proxy debugging was unreliable with connection failures and emulator incompatibility
- New mini app reduced build times from 3-4 minutes to 1-1.5 minutes
- Refactored module registration to support new Android module dependencies
- Shared JSON test files with iOS team via git submodule
A standalone testing application eliminated flaky proxy tools and halved build times for UI testing in Strava's server-driven mobile architecture.
About This Article
Strava's Android team had module registration spread across multiple Android modules and feature modules. As dependencies evolved during Guild week refactoring, the codebase became hard to maintain.
Xin Yi Chen restructured the dependency architecture by creating view module lists in each Android module. These lists were then collected into a master list in the main application module for centralized management.
The refactored architecture made it possible to build a standalone mini application. This eliminated Charles Proxy unreliability and enabled cross-platform JSON testing through a shared iOS git submodule, giving them consistent test coverage.