Best Practices for Unit Testing at Revolut
Article Summary
Revolut's iOS team ships weekly updates with minimal regression. Their secret? Making unit tests actually fun to write.
Arsen Gasparyan from Revolut's mobile team breaks down the friction points that make developers avoid writing tests. He shares three practical patterns that transformed their testing workflow from a chore into a productive, enjoyable practice.
Key Takeaways
- Sample functions create test objects with default values, override only what matters
- MockFunc object replaces verbose closure based mocks with clean one liners
- Builder pattern moves setup noise out of test cases for better readability
- Each pattern solves specific friction: verbose setup, cluttered mocks, or noisy preparation
Three simple patterns (sample functions, MockFunc, and builders) removed the friction that made iOS developers avoid writing unit tests at Revolut.
About This Article
Revolut's developers had to fill in every property of their business models during test setup, even when they only needed one or two. This made writing tests feel like a chore, so people skipped comprehensive unit test coverage.
Arsen Gasparyan created factory methods that came with sensible defaults for each property. Developers could now spin up test instances with just a few parameters, and the functions stayed pure without hardcoded values like Date().
Revolut's iOS team combined sample functions, MockFunc objects, and builders to keep test coverage high while shipping weekly updates. They saw minimal regression, which showed that removing friction from testing makes it sustainable when you're working at scale.