Want to dive deeper into each test type? I wrote a detailed breakdown of UI testing types with practical examples: alexzh.com/not-all-ui-...

When you match the right type of tests to the right job, your E2E suite shrinks dramatically—and execution time stops being a problem.

Stop asking "how do we make E2E faster?" Start asking "should this even be an E2E test?"

What percentage of your UI tests are currently E2E?

The only way to make your UI tests fast and reliable is to replace most of your E2E tests with different test types:

• E2E tests → Verify production environment integrations
• UI tests with fake data → Verify state handling (loading, success, error)
• Screenshot tests → Verify the pixel perfectness

Most teams believe end-to-end tests are the only UI testing strategy available. So they focus on improving infrastructure or switching to a "better" framework.

But E2E tests were never designed to test everything. They verify one thing: how your app talks to the production environment.

But, there's a crucial point: your tests might pass even if your UI is broken.

That's why I'm writing a book on Visual Testing for Android.

Join the waitlist to find out when it launches and to access early bird pricing: alexzh.com/android-vis...

3/3 I realized this after spending some time improving my layout for the medium layout and checking it on a single device. We should design layouts based on screen sizes, not device types.

Does your application support foldable devices?

2/3 Here's the problem:
Google's window size classes aren't device categories—they're viewport measurements. The Pixel 9 Pro Fold jumps straight from compact to expanded, never using medium.

On the other side, Samsung's Z Fold 5 uses medium.

Same device category, but different screen sizes.

Your preview functions can be used not only for development but also as a tool to releasing apps without pixel imperfections.

Want to dive deeper into visual testing? Subscribe to my newsletter. Plus, you’ll be the first to know when my book on visual testing is released!

alexzh.com/

#AndroidDev

You now need only to make minor adjustments to implement visual tests.

Start strategically:
• Convert your design system and/or common components first
• Add preview functions for the most critical screens
• Gradually expand coverage to less critical screens

But if you are already using Jetpack Compose, you can use ComposablePreviewScanner or the Compose Preview Screenshot Testing framework to transform your preview functions into visual tests.

You likely already created a preview function, which was the hard part.

3. Number formatting varies between countries.

Let's compare:

• US: 12,345,678.9
• FR: 12 345 678,9

Use "NumberFormat.getNumberInstance(locale)." for number formatting.

Which of these has caused issues in your apps?

2. Date formats are often a reason for user confusion.

Is "01/02/2025" January 2nd or February 1st? Actually, it depends on the locale.

• US: MM/DD/YYYY
• UK: DD/MM/YYYY

Use "DateTimeFormatter" to format dates based on locale.

Apply a similar approach to time formatting.

1. Currency formatting differs by country:

• US: $1,234.56
• DE: 1.234,56 €

Use "NumberFormat.getCurrencyInstance(locale)" for proper currency symbol positioning.