{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreib7a6qxyj4b5khtcywu6kwjgslrsys6lrczeomwtj573h3u4pcnyy",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mohf6rlrhnh2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreid2mrd4v7cxxjlrk6vltjl4h2vzrzyn2ifubg7hadgilqj7kduic4"
    },
    "mimeType": "image/webp",
    "size": 168744
  },
  "path": "/mayvinrmm/stop-editing-config-files-for-every-appium-run-use-spring-profiles-5dnf",
  "publishedAt": "2026-06-17T02:54:42.000Z",
  "site": "https://dev.to",
  "tags": [
    "appium",
    "springboot",
    "testing",
    "java",
    "https://www.mobile-automation.io/mobile-test-configuration-management-part-1/",
    "@Value",
    "@ConfigurationProperties"
  ],
  "textContent": "If your mobile test setup requires opening a properties file and hand-editing the platform, UDID, or app path before every run, that workflow falls apart the moment you move to CI. You can't edit a file inside a pipeline, and a wall of -D flags is its own maintenance burden.\n\nThe fix is to stop treating configuration as one flat file and start treating it as independent dimensions — platform, device, environment, test phase — each a named profile that activates on its own. Spring Boot composes them from SPRING_PROFILES_ACTIVE, so switching from Android to iOS becomes a profile name, not a diff.\n\nThis guide walks through that refactor on a real Appium + Spring Boot framework:\n\n  * 🧩 Replace scattered @Value annotations with a typed @ConfigurationProperties config object\n  * 🔌 Move DriverManager to constructor injection so values have a single source\n  * 📂 Split application.properties into a base file plus platforms.yml and devices.yml\n  * 🔐 Keep personal UDIDs and app paths in git-ignored local profile files\n  * 🧭 Understand Spring's exact precedence order so overrides are predictable\n  * 🔄 Map old Article 5 property keys to the new driver.* prefix\n\n\n\nOne detail worth knowing before you start: Spring's precedence runs base file → imported profiles → auto-discovered files → environment variables → command-line properties. The article keeps one deliberate\nexception — driver.udid — where a local file is allowed to override the placeholder, and it explains exactly why that exception earns its place.\n\nThis is Part 1, covering the platform and device dimensions. Part 2 adds environment, test phase, and cloud credentials.\n\n👉 Read the full guide here: https://www.mobile-automation.io/mobile-test-configuration-management-part-1/",
  "title": "Stop Editing Config Files for Every Appium Run — Use Spring Profiles"
}