Emulators vs real devices in Testing Fundamentals - Automation Approaches Compared

Verify app behavior on emulator and real device

Preconditions (2)

Step 1: Launch the app on the emulator

Step 2: Navigate to the login screen

Step 3: Enter username 'testuser' and password 'Test@1234'

Step 4: Click the login button

Step 5: Verify the home screen is displayed

Step 6: Repeat steps 1-5 on the real device

✅ Expected Result: The app should successfully log in and display the home screen on both emulator and real device without errors.

Automation Requirements - Appium with Python

Assertions Needed:

Verify login button is clickable

Verify home screen element is visible after login

Best Practices:

Use explicit waits to wait for elements

Use Page Object Model to separate locators and actions

Handle device capabilities separately for emulator and real device

Automated Solution

Testing Fundamentals

from appium import webdriver
from appium.webdriver.common.appiumby import AppiumBy
from selenium.webdriver.support.ui import WebDriverWait
from selenium.webdriver.support import expected_conditions as EC

class LoginPage:
    def __init__(self, driver):
        self.driver = driver
        self.username_field = (AppiumBy.ACCESSIBILITY_ID, "username_input")
        self.password_field = (AppiumBy.ACCESSIBILITY_ID, "password_input")
        self.login_button = (AppiumBy.ACCESSIBILITY_ID, "login_button")

    def enter_username(self, username):
        WebDriverWait(self.driver, 10).until(
            EC.visibility_of_element_located(self.username_field)
        ).send_keys(username)

    def enter_password(self, password):
        WebDriverWait(self.driver, 10).until(
            EC.visibility_of_element_located(self.password_field)
        ).send_keys(password)

    def tap_login(self):
        WebDriverWait(self.driver, 10).until(
            EC.element_to_be_clickable(self.login_button)
        ).click()

class HomePage:
    def __init__(self, driver):
        self.driver = driver
        self.home_screen_element = (AppiumBy.ACCESSIBILITY_ID, "home_screen")

    def is_displayed(self):
        return WebDriverWait(self.driver, 10).until(
            EC.visibility_of_element_located(self.home_screen_element)
        ) is not None

def create_driver(device_name, platform_version, app_path):
    desired_caps = {
        "platformName": "Android",
        "deviceName": device_name,
        "platformVersion": platform_version,
        "app": app_path,
        "automationName": "UiAutomator2"
    }
    return webdriver.Remote("http://localhost:4723/wd/hub", desired_caps)


def test_login_on_device(device_name, platform_version, app_path):
    driver = create_driver(device_name, platform_version, app_path)
    login_page = LoginPage(driver)
    home_page = HomePage(driver)

    login_page.enter_username("testuser")
    login_page.enter_password("Test@1234")
    login_page.tap_login()

    assert home_page.is_displayed(), f"Home screen not displayed on {device_name}"

    driver.quit()


if __name__ == "__main__":
    # Test on emulator
    test_login_on_device("emulator-5554", "13.0", "/path/to/app.apk")

    # Test on real device
    test_login_on_device("real_device_01", "12.0", "/path/to/app.apk")

This script uses Appium with Python to automate the login test on both emulator and real device.

We define LoginPage and HomePage classes to separate page elements and actions, following the Page Object Model.

The create_driver function sets up the driver with device-specific capabilities, so we can reuse it for emulator and real device by passing different parameters.

Explicit waits ensure the script waits for elements to be visible or clickable before interacting, avoiding timing issues.

The test_login_on_device function performs the login steps and asserts the home screen is visible, confirming successful login.

Finally, the script runs tests on both emulator and real device by calling test_login_on_device with appropriate device names and platform versions.

Common Mistakes - 3 Pitfalls

Using hardcoded sleep instead of explicit waits

Mixing locators inside test code instead of using Page Object Model

Using same device capabilities for emulator and real device

Bonus Challenge

Now add data-driven testing with 3 different username and password combinations.

Show Hint

Practice

1. Which of the following is a key advantage of using an emulator in software testing?

easy

A. It allows quick testing without needing physical hardware

B. It guarantees exact hardware behavior

C. It always detects real-world network issues

D. It requires no setup or configuration

Solution

1. Step 1: Understand emulator purpose

   Emulators simulate devices on a computer, enabling testing without physical devices.

2. Step 2: Compare options

   Only It allows quick testing without needing physical hardware correctly states the quick testing advantage; others are incorrect or exaggerated.

3. Final Answer:

   It allows quick testing without needing physical hardware -> Option A

4. Quick Check:

   Emulator = Quick testing without hardware [OK]

Hint: Emulators run on computers, so no device needed [OK]

Common Mistakes:

• Thinking emulators perfectly mimic hardware
• Assuming emulators catch all network issues
• Believing emulators need zero setup

2. Which syntax correctly describes a real device in testing?

easy

A. device = Emulator()

B. device = VirtualMachine()

C. device = Simulator()

D. device = RealDevice()

Solution

1. Step 1: Identify correct class for real device

   Real devices are represented by RealDevice() in typical testing code.

2. Step 2: Eliminate other options

   Emulator, Simulator, and VirtualMachine are not real devices but virtual or simulated environments.

3. Final Answer:

   <code>device = RealDevice()</code> -> Option D

4. Quick Check:

   Real device code uses RealDevice() [OK]

Hint: Real device uses RealDevice() syntax [OK]

Common Mistakes:

• Confusing emulator or simulator with real device
• Using virtual machine as real device
• Mixing syntax names

3. Consider this test code snippet:

device = Emulator()
result = device.run_app('TestApp')
print(result)

What is the most likely output?

medium

A. 'App ran successfully on emulator'

B. 'App crashed on real device'

C. 'Network error detected'

D. 'Hardware failure detected'

Solution

1. Step 1: Analyze code behavior on emulator

   The code runs the app on an emulator, which usually simulates success unless errors are coded.

2. Step 2: Match output to emulator context

   'App ran successfully on emulator' matches expected emulator success message; others mention real device or errors unlikely here.

3. Final Answer:

   'App ran successfully on emulator' -> Option A

4. Quick Check:

   Emulator run = success message [OK]

Hint: Emulator usually shows success unless error coded [OK]

Common Mistakes:

• Choosing real device output for emulator code
• Assuming network or hardware errors always appear
• Ignoring code context

4. A tester runs a test on an emulator but notices the app behaves differently on a real device. What is the most likely cause?

medium

A. The test code is incorrect

B. The emulator does not perfectly simulate hardware features

C. The real device has a software bug

D. The emulator has a network failure

Solution

1. Step 1: Understand emulator limitations

   Emulators simulate devices but cannot perfectly mimic hardware or environment differences.

2. Step 2: Evaluate other options

   Software bugs or test code errors are possible but less likely than emulator limitations causing behavior differences.

3. Final Answer:

   The emulator does not perfectly simulate hardware features -> Option B

4. Quick Check:

   Emulator limits cause behavior differences [OK]

Hint: Emulators miss some hardware details [OK]

Common Mistakes:

• Blaming test code without checking emulator limits
• Assuming real device always has bugs
• Ignoring emulator simulation gaps

5. You want to test an app's camera feature. Which approach best ensures accurate testing results?

hard

A. Use only an emulator because it is faster

B. Use only a real device because it shows true hardware behavior

C. Use emulator for early tests and real device for final camera tests

D. Use neither; testing camera is not needed

Solution

1. Step 1: Consider testing stages

   Early tests can use emulators for speed; final tests need real devices for hardware accuracy.

2. Step 2: Apply to camera feature

   Camera depends on hardware, so real device testing is essential before release.

3. Final Answer:

   Use emulator for early tests and real device for final camera tests -> Option C

4. Quick Check:

   Early emulator + final real device = best practice [OK]

Hint: Combine emulator speed with real device accuracy [OK]

Common Mistakes:

• Relying only on emulator for hardware features
• Skipping real device testing
• Ignoring testing stages