DEV Community: Mayvin Ramasawmy

Keep Appium out of your test code: BasePage + lazy locators

Mayvin Ramasawmy — Tue, 26 May 2026 12:56:55 +0000

If your test methods import AndroidDriver, call findElement directly, or know what a locator strategy is, your tests are coupled to Appium. The day a selector changes or the driver setup moves, that coupling spreads the edit across every test you've written.

The fix is an abstraction layer your tests talk to instead. Tests describe intent — loginScreen.signIn(user) — and never see the driver underneath.

What the article builds:

🧱 A BasePage that runs PageFactory.initElements with AppiumFieldDecorator, so every screen object inherits element wiring for free
🐌 Lazy locators — @AndroidFindBy fields resolve to real elements at interaction time, not at construction
🔌 A Spring-managed DriverManager that owns the session so screen objects receive an already-initialized driver
💉 Constructor injection that passes that single driver down through the framework
⚖️ The SRP and DIP reasoning for why the driver lives in one place

One concrete detail worth knowing: because AppiumFieldDecorator makes locators lazy, instantiating a screen object does not query the UI. Nothing touches the device until you actually call a method that uses a field. That's why you can construct screen objects in a constructor without the app being on the right screen yet — a common source of confusion when people expect @AndroidFindBy to fail immediately on a missing element.

This is Article 3 of a series building a mobile framework end to end. If your tests are tangled up with Appium internals, this is the layer that separates them.

👉 Read the full guide here: https://www.mobile-automation.io/driver-setup-screen-objects-mobile-framework/

How to structure an Appium framework that scales beyond one team

Mayvin Ramasawmy — Wed, 20 May 2026 14:55:54 +0000

Single-module Appium frameworks work great — until a second team needs to use them.

It starts small. A shared utility gets copy-pasted into another repo because it's quicker than figuring out how to share it properly. One team upgrades Appium. The other can't follow without breaking half their tests. What started as one shared framework is now three slightly different versions, each maintained by a different team, with no clear owner and no easy way to keep them in sync.

The answer isn't more coordination. It's an architectural decision made early: stay single-module, or build something teams can share without forking.

Here's what the full guide walks through:

🧱 When a single module is genuinely enough (and when it isn't)
📦 Setting up a Maven multi-module project with a clean parent POM
🌱 Why Spring Boot integration has to happen early, not retroactively
🔀 The dependency direction rule that keeps your core reusable
🏗️ How a core + team-tests split maps to multi-team scaling later
⚠️ BOM imports, packaging types, and module naming — the Maven mistakes that silently break builds

When you bring Spring Boot into a Maven framework, import the BOM in your parent POM's instead of inheriting from spring-boot-starter-parent. Inheriting forces your parent POM to extend Spring's parent, which takes over your inheritance hierarchy. The BOM gives you the same managed versions without that trade-off — Spring Boot dependencies need no explicit version declarations.

The full guide covers the parent POM setup, module layout, dependency graph, and the architectural decisions that make this framework usable by 20+ teams without forking.

👉 Read the full guide here: https://www.mobile-automation.io/scalable-mobile-test-framework/

Stop writing test scripts. Start building a mobile automation framework.

Mayvin Ramasawmy — Sat, 16 May 2026 16:12:14 +0000

Most mobile test automation projects start the same way: strong intentions, decent coverage, tests that mostly pass. Then the app ships a new screen. Or the team doubles. Or you add iOS alongside Android. And suddenly the suite that looked fine at 50 tests is a nightmare at 500.

The culprit is almost never the tests themselves — it's the absence of architecture underneath them.

Here's what the article covers:

🧱 The 7 quality attributes (maintainability, reliability, extensibility, and more) that separate frameworks that scale from ones that collapse
🔧 How SOLID principles — SRP, OCP, LSP, ISP, DIP — apply directly to test automation code, with practical analogies for each
📱 Why the Page Object Model is the right structural default for mobile, and what it actually gives you
📦 How multi-module project architecture keeps team test code isolated without duplicating shared logic
⚙️ Configuration management for environments, device profiles, and test profiles — with zero code changes at runtime
🤖 How to design your framework now so AI tooling (self-healing selectors, AI-generated tests) can plug in later

One thing the article names explicitly that most teams skip: hard-coded sleeps (Thread.sleep(3000)) aren't just a minor bad habit — they're a root cause of flaky tests and a direct waste of machine resources at scale. It's a small call-out, but it's the kind of thing that quietly poisons a suite long before anyone traces the flakiness back to it.

This is the foundation article for a full framework build series. Everything that follows — Maven multi-module setup, driver configuration, BDD integration, parallel execution, device farms — builds on the blueprint laid out here.

👉 Read the full guide here: https://www.mobile-automation.io/why-mobile-test-automation-frameworks-fail/

I write practical guides on mobile test automation and AI tooling at mobile-automation.io (https://www.mobile-automation.io/). If this was useful, feel free to follow along.

The 9-Step Path to Mobile Test Automation with Appium 3

Mayvin Ramasawmy — Wed, 06 May 2026 17:09:28 +0000

Setting up Appium for the first time is harder than it should be. It's not one thing — it's five things that all have to work together: the right driver, the right SDK, the right capabilities, the right device config. Miss one and your session won't even start.

Most guides online don't help much either. A lot of them are still written for older Appium versions, and the ecosystem has changed significantly.

This guide is the learning path I wish existed when I started — 9 steps, in order, from zero to writing real end-to-end tests on Android and iOS.

Here's what's covered:

📦 Installing Appium 3 and running Appium Doctor to verify your setup
🤖 Android setup — UIAutomator2 driver, Android Studio, SDK, and emulators
🍎 iOS setup — Xcode, simulators, WebDriverAgent, and real device gotchas
🔍 Appium Inspector — finding locators and understanding your app's UI structure
⚙️ Capabilities — the config layer that controls how Appium launches your app
🧪 End-to-end tests — login flows, gestures, and drag-and-drop on both platforms

One thing worth knowing upfront: iOS setup is genuinely more involved than Android. Xcode alone has several configuration steps that catch people off guard. The iOS article covers all of them, including WebDriverAgent and real device provisioning, so you're not left guessing.

If you're starting from scratch or feel like your setup is fragile, this path is designed for you.

👉 Read the full guide here: https://www.mobile-automation.io/getting-started-with-appium/

I write practical guides on mobile test automation and AI tooling at mobile-automation.io. If this was useful, feel free to follow along.