How to Test Filters And Sorting on Android (Complete Guide)

Filters and sorting are the UI mechanisms that let users turn a large data set into a manageable view. In e‑commerce apps a filter might narrow products by price, brand, or availability; in a news rea

Motivation: Why Filters and Sorting Deserve Dedicated Test Effort

Filters and sorting are the UI mechanisms that let users turn a large data set into a manageable view. In e‑commerce apps a filter might narrow products by price, brand, or availability; in a news reader sorting could arrange articles by recency, popularity, or relevance. When these controls misbehave the user experience degrades instantly—items disappear, wrong order appears, or the app crashes while trying to apply a predicate. Because the logic often lives in the presentation layer, it is easy to overlook during unit testing, yet the failure surface is wide: UI state, backend queries, caching, and accessibility services all interact. A dedicated test effort catches regressions that would otherwise slip into production and generate support tickets, poor ratings, or abandoned carts.

What Typically Breaks in Production

Understanding these patterns helps you build a test matrix that covers not only the happy path but also the failure modes that surface only under real‑world conditions.

Comprehensive Test Matrix

Below is a matrix you can copy into a test plan spreadsheet. Each row represents a test scenario; columns indicate the dimension you validate. Use ✅ for pass, ❌ for fail, and ⚠️ for flaky or conditional outcomes.

Feel free to add rows for specific product domains (e.g., date range filter for events, rating filter for reviews). The matrix gives you a concrete checklist that can be turned into automated test cases or manual exploratory sessions.

Manual Testing Approach – Step‑by‑Step

1. Prepare the Test Environment

• Device/emulator: Use a recent Android version (API 33+) and also test on at least one older API (e.g., 21) to catch deprecated API usage.
• Developer options: Enable “Show layout bounds”, “Strict mode”, and “Disable HW overlays” to overdraw issues.
• Logging: Connect via adb logcat -v time | grep -E "Filter|Sort|ViewModel" to capture runtime traces.

2. Baseline Exploration

Launch the app and navigate to the screen containing the filter/sort UI.

• Note the initial state: which chips are selected, default sort order, visible item count.
• Take a screenshot for reference (adb exec-out screencap -p > baseline.png).

3. Happy‑Path Validation

1. Tap a single filter chip → verify it becomes highlighted.
2. Observe the list update: item count changes, no stale items remain.
3. Tap “Apply” (if present) → confirm network request matches expected query (use adb logcat or a proxy like Charles).
4. Change sort order → confirm list re‑renders with correct comparator.

4. Error‑Path Injection

• Simulate backend failures: use a tool like HttpCanary or Charles to return 500 or malformed JSON when the filter request is made.
• Verify that an error toast or empty state appears, and the UI does not crash.

5. Edge‑Case Execution

• Rapid interaction: Use a scripted monkey command (adb shell monkey -p com.example.app -c android.intent.category.LAUNCHER 500 -throttle 200) focusing on the filter area to stress‑test debouncing.
• Configuration change: Rotate device while a filter is applied; ensure the UI retains selections and the list does not flicker.
• Long text: Paste a 200‑character string into a text‑filter field; confirm the app either truncates, validates, or shows a clear error.

6. Accessibility Checks

• Turn on TalkBack and navigate to each filter chip using swipe gestures. Confirm each chip announces its label and state (selected/unselected).
• Use Accessibility Scanner (from Play Store) to detect missing contentDescriptions, low contrast, or touch targets <48 dp.
• Increase system font size to 200 % and verify layout does not truncate or overlap.

7. Security/Privacy Scan

• Enable Network Security Config logging to ensure no clear‑text HTTP requests contain filter parameters.
• If the app sends analytics, inspect the payload with a proxy to confirm that raw filter strings (especially PII like email or phone) are not included.

8. Performance Profiling

• Open Android Studio Profiler, select the UI thread, and record while applying a multi‑choice filter.
• Look for spikes >16 ms (jank) or sustained >200 ms work on the main thread. If present, move heavy filtering to a Coroutine or WorkManager.

9. Localization & RTL

• Change device language to Arabic (or Hebrew) and verify that filter icons, dropdown arrows, and sort icons are mirrored correctly.
• Confirm that text alignment in filter chips respects RTL without clipping.

10. Cross‑Session State

• Apply a filter, then press home and relaunch the app after a few minutes. The filter should either persist (if designed) or reset to default per product spec.
• Use adb shell dumpsys activity activities | grep mResumedActivity to verify the activity lifecycle.

11. Persona‑Driven Exploration

• Curious: Tap every chip, long‑press to see tooltips, try hidden gestures.
• Impatient: Tap filter, then immediately press back; ensure no crash or leak.
• Elderly: Use large font, test touch targets.
• Adversarial: Insert special characters (' OR 1=1 --) into text filters; verify sanitization.

Document any deviation from the matrix as a bug, attaching logs, screenshots, and steps to reproduce.

Automated Approaches – Espresso, UIAutomator, and Appium

Espresso for Filter UI

@RunWith(AndroidJUnit4::class)
class FilterSortTest {

    @get:Rule
    val activityRule = ActivityScenarioRule(MainActivity::class.java)

    @Test
    fun `single choice filter updates list`() {
        // Arrange – ensure we start from known state
        onView(withId(R.id.btn_reset_filters)).perform(click())

        // Act – tap the Electronics chip
        onView(withText("Electronics")).perform(click())

        // Assert – chip appears selected
        onView(withText("Electronics"))
            .check(matches(isSelected()))

        // Assert – list reflects filter (e.g., at least one item shown)
        onView(withId(R.id.recycler_view))
            .check(matches(hasMinimumChildCount(1)))
    }

    @Test
    fun `sort descending shows highest price first`() {
        onView(withId(R.id.spinner_sort)).perform(click())
        onView(withText("Price: High → Low")).perform(click())

        onView(withId(R.id.recycler_view))
            .check(matches(
                atPosition(
                    0,
                    hasDescendant(withText(matches(`startsWith`("$"))))
                )
            ))
    }
}

*Key points*:

• Use IdlingResource if the app performs network requests after a filter; otherwise Espresso may assert before the list updates.
• Parameterize the test with @ParameterizedTest (via JUnit‑Params) to run the same logic for each filter category.

UIAutomator for Cross‑App Scenarios

If your filter launches a separate picker activity (e.g., date range), UIAutomator can interact across process boundaries:

public class FilterUiAutomatorTest {

    private UiDevice device;

    @Before
    public void setUp() throws Exception {
        device = UiDevice.getInstance(InstrumentationRegistry.getInstrumentation());
    }

    @Test
    public void dateRangeFilterAppliesCorrectly() throws UiObjectNotFoundException {
        // Open filter drawer
        device.findObject(new UiSelector().descriptionContains("Open filters")).click();

        // Set start date
        UiObject startDate = device.findObject(new UiSelector()
                .resourceId("com.example.app:id/start_date"));
        startDate.click();
        device.findObject(new UiSelector().text("15")).click(); // day 15

        // Set end date
        UiObject endDate = device.findObject(new UiSelector()
                .resourceId("com.example.app:id/end_date"));
        endDate.click();
        device.findObject(new UiSelector().text("22")).click(); // day 22

        // Confirm
        device.findObject(new UiSelector().text("Apply")).click();

        // Verify that at least one item matches the range
        UiObject list = device.findObject(new UiSelector()
                .resourceId("com.example.app:id/item_list"));
        assertTrue(list.getChildCount() > 0);
    }
}

Appium for Hybrid or WebViews

When part of the filter UI lives in a WebView (common for hybrid apps), Appium lets you switch contexts:

from appium import webdriver
from appium.webdriver.common.mobileby import MobileBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

caps = {
    "platformName": "Android",
    "deviceName": "Pixel_4_API_33",
    "app": "/path/to/app.apk",
    "automationName": "UiAutomator2"
}
driver = webdriver.Remote("http://localhost:4723/wd/hub", caps)

# Switch to native context to open filter
driver.find_element(MobileBy.ACCESSIBILITY_ID, "Open filters").click()
# Switch to WebView
WebDriverWait(driver, 10).until(lambda d: len(d.contexts) > 1)
driver.context = driver.contexts[1]   # usually "WEBVIEW_com.example.app"

# Interact with HTML filter
driver.find_element(MobileBy.ID, "category-select").send_keys("Electronics")
driver.find_element(MobileBy.ID, "apply-btn").click()

# Switch back and validate list
driver.context = driver.contexts[0]
assert driver.find_element(MobileBy.ID, "item_count").text != "0"
driver.quit()

Leveraging SUSA for Autonomous, Persona‑Driven Discovery

SUSA can explore the filter/sort screen without any test code. After installing the agent:

pip install susatest-agent
susatest explore --apk path/to/app.apk --personas curious impatient elderly adversarial

The agent will:

• Launch the app, locate filter chips via UI hierarchy, and try every combination it can infer (single‑choice, multi‑choice, range).
• Simulate each persona’s timing: the *impatient* persona taps and backs out quickly, the *elderly* persona uses long presses and waits for animations, the *adversarial* persona injects strings like