Python SDET Bootcamp

Python SDET Bootcamp

Lesson 53: Your First Mobile Script — Launching the Calculator and Proving 2 + 2 = 4

HandsOn Automation Bootcamp's avatar
HandsOn Automation Bootcamp
May 02, 2026
∙ Paid

The Junior Trap: “Just Add a Sleep”

Picture this. A junior dev opens Stack Overflow, finds a three-year-old Appium snippet, and writes:

driver.find_element(By.ID, "com.android.calculator2:id/digit_2").click()
time.sleep(3)
driver.find_element(By.ID, "com.android.calculator2:id/op_add").click()
time.sleep(3)
result = driver.find_element(By.ID, "com.android.calculator2:id/result").text
assert result == "4"

On their laptop at home, running on a warmed-up emulator with 32 GB RAM, this works every time. They commit. It gets merged. The CI pipeline runs it on a fresh Docker container that has to cold-boot an Android Virtual Device (AVD) from scratch.

It fails.

Sometimes it fails because the emulator isn’t ready. Sometimes it fails because the app is still animating. Sometimes it passes by sheer luck. This is called flakiness, and it is the single most dangerous thing in a test suite. A flaky test is worse than no test at all — it trains your team to ignore red builds, and the day a real bug appears, everyone assumes it’s another flaky test.

The time.sleep(3) approach has three structural problems:

  1. It’s a guess. Three seconds is arbitrary. On a slow CI runner or a cloud device farm, the emulator might need 90 seconds. On a fast machine you’re wasting time.

  2. It doesn’t know what it’s waiting for. Sleep doesn’t care if the element is there or not. It just burns clock.

  3. It compounds. Ten test steps with 3-second sleeps = 30 wasted seconds per test run. With 100 tests, that’s 50 minutes of doing absolutely nothing.


The Failure Mode: Race Conditions and Stale Elements

When you use time.sleep, you race the UI. You either win (element was ready before sleep ended) or you lose:

selenium.common.exceptions.NoSuchElementException: 
  Message: An element could not be located on the page using 
  the given search parameters.

Or worse, you find the element during the sleep window, the app re-renders mid-animation, and you get:

selenium.common.exceptions.StaleElementReferenceException:
  Message: Element is no longer attached to the DOM

The app moved on. Your reference is a ghost.


The UQAP Solution: Explicit Waits + Page Object Model

User's avatar

Continue reading this post for free, courtesy of HandsOn Automation Bootcamp.

Or purchase a paid subscription.
© 2026 SystemDR Inc · Privacy ∙ Terms ∙ Collection notice
Start your SubstackGet the app
Substack is the home for great culture