Mobile Test Reporting & CI Integration
Mobile test results need to flow into the same CI/CD pipeline as web and API tests. This topic covers integrating Appium tests with GitHub Actions, generating rich reports with device-specific screenshots and video recordings, and building a robust mobile testing pipeline that catches regressions before release.
Mobile CI/CD Pipeline
# ══════════════════════════════════════════════════════════════
# GITHUB ACTIONS: MOBILE TEST PIPELINE
# .github/workflows/mobile-tests.yml
# ══════════════════════════════════════════════════════════════
name: Mobile Test Suite
on:
push:
branches: [main, develop]
pull_request:
branches: [main]
jobs:
mobile-tests:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Setup Python
uses: actions/setup-python@v5
with:
python-version: '3.12'
- name: Install Dependencies
run: |
pip install Appium-Python-Client pytest pytest-html allure-pytest
# Option A: BrowserStack (uses cloud devices — no local setup)
- name: Run Mobile Tests on BrowserStack
env:
BROWSERSTACK_USERNAME: ${{ secrets.BS_USERNAME }}
BROWSERSTACK_ACCESS_KEY: ${{ secrets.BS_ACCESS_KEY }}
APP_URL: ${{ secrets.BS_APP_URL }} # Pre-uploaded APK/IPA hash
run: |
pytest tests/mobile/ --alluredir=./allure-results --html=./reports/mobile-report.html -v --tb=short
# Option B: Local Emulator (slower, but free)
# - name: Start Android Emulator
# uses: reactivecircus/android-emulator-runner@v2
# with:
# api-level: 34
# script: pytest tests/mobile/ -v
- name: Upload Test Reports
if: always()
uses: actions/upload-artifact@v4
with:
name: mobile-test-results
path: |
./reports/
./allure-results/
retention-days: 30
- name: Upload Allure Report to GitHub Pages
if: github.ref == 'refs/heads/main'
uses: peaceiris/actions-gh-pages@v3
with:
github_token: ${{ secrets.GITHUB_TOKEN }}
publish_dir: ./allure-report
# ── MOBILE-SPECIFIC PYTEST CONFTEST WITH REPORTING ────────────
import allure
import pytest
from datetime import datetime
@pytest.fixture(scope="function")
def android_driver(request):
from appium import webdriver
# ... driver setup ...
yield driver
# On failure: capture screenshot and page source for report
if request.node.rep_call.failed:
timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
# Screenshot attached to Allure report
allure.attach(
driver.get_screenshot_as_png(),
name=f"failure_screenshot_{timestamp}",
attachment_type=allure.attachment_type.PNG
)
# Page source (XML dump of current screen hierarchy)
allure.attach(
driver.page_source,
name=f"page_source_{timestamp}",
attachment_type=allure.attachment_type.XML
)
driver.quit()Quick Quiz — Mobile Testing with Appium
Common Mistakes
- Not uploading screenshots on failure — mobile failures without screenshots require re-running the test; always capture screenshots in teardown
- No page source on failure — the XML page source dump shows the full element hierarchy at the moment of failure; critical for debugging remote (CI) failures
- Running all mobile tests on every PR — mobile tests are slow; run smoke mobile tests on PRs, full mobile regression on merge to main
- Not tagging tests by device priority — use @pytest.mark.mobile_smoke for tier-1 device tests; run them first to get fast signal
Tip
Tip
Practice Mobile Test Reporting CI Integration in small, isolated examples before integrating into larger projects. Breaking concepts into small experiments builds genuine understanding faster than reading alone.
Technical diagram.
Practice Task
Note
Practice Task — (1) Write a working example of Mobile Test Reporting CI Integration from scratch without looking at notes. (2) Modify it to handle an edge case (empty input, null value, or error state). (3) Share your solution in the Priygop community for feedback.
Common Mistake
Warning
A common mistake with Mobile Test Reporting CI Integration is skipping edge case testing — empty inputs, null values, and unexpected data types. Always validate boundary conditions to write robust, production-ready software testing code.
Key Takeaways
- Mobile test results need to flow into the same CI/CD pipeline as web and API tests.
- Not uploading screenshots on failure — mobile failures without screenshots require re-running the test; always capture screenshots in teardown
- No page source on failure — the XML page source dump shows the full element hierarchy at the moment of failure; critical for debugging remote (CI) failures
- Running all mobile tests on every PR — mobile tests are slow; run smoke mobile tests on PRs, full mobile regression on merge to main