在Page Object Model模式下，如何实现Appium测试的指定页面导航？

Great question—transitioning to the Page Object Model (POM) when you already have existing test navigation logic can feel a bit awkward at first, but there are clean, maintainable ways to align your setup with POM best practices. Let’s break this down.

Core POM Rule to Remember #

First, a critical principle: Page classes should represent a UI state, not automatically navigate to that state. Putting navigation logic in a Page's init method is a bad idea because it couples the Page object to a specific test flow—you might later want to navigate to that UI from a different starting point (e.g., from a notification, not the home screen), and an init-based navigation would break that flexibility.

Refactoring Your Existing Setup #

Your current AppTest with startApp() and test-specific getToUI() methods is a great foundation—we just need to shift navigation logic into Page objects where it belongs. Here's how:

1. Move app initialization/entry flow to your entry Page classes
   Your SplashScreenActivity should have a corresponding SplashScreenPage that handles waiting for the splash to finish and navigating to the login screen. Then, a LoginPage will handle the test user login and return the HomePage once complete. This replaces the hardcoded logic in your original startApp() with reusable Page methods.

2. Let each Page own its navigation to other Pages
   Instead of having test classes handle clicks to navigate (like your old getToUI()), give each Page methods that return the target Page when a navigation action is performed. For example, your HomePage should have a navigateToSettings() method that clicks the settings button and returns a SettingsPage instance.

3. Simplify test class setup
   Your test classes will still inherit from AppTest, but instead of implementing getToUI(), they'll chain Page navigation methods starting from the HomePage returned by startApp().

Example Kotlin Code Snippets #

Let’s translate this into code to make it concrete:

First, Update Your BaseTest and Page Class Foundation

Ensure all Page classes have access to your base system-level methods (like waitForElement) by passing the BaseTest instance or Appium driver:

// BaseTest remains your system-level helper
open class BaseTest {
    protected lateinit var driver: AndroidDriver<MobileElement>

    fun waitForElement(by: By): MobileElement {
        // Your existing wait implementation
    }

    // Other system methods: swipeScreen, waitForElementToDisappear, etc.
}

SplashScreenPage (Entry Point)

class SplashScreenPage(private val baseTest: BaseTest) {
    private val splashLogo = baseTest.waitForElement(By.id("com.your.app:id/splash_logo"))

    fun waitAndProceedToLogin(): LoginPage {
        baseTest.waitForElementToDisappear(splashLogo)
        return LoginPage(baseTest)
    }
}

LoginPage (Handles Authentication)

class LoginPage(private val baseTest: BaseTest) {
    private val usernameField = baseTest.waitForElement(By.id("com.your.app:id/username"))
    private val passwordField = baseTest.waitForElement(By.id("com.your.app:id/password"))
    private val loginBtn = baseTest.waitForElement(By.id("com.your.app:id/login_btn"))

    // Fluent methods for form input
    fun enterUsername(username: String): LoginPage {
        usernameField.sendKeys(username)
        return this
    }

    fun enterPassword(password: String): LoginPage {
        passwordField.sendKeys(password)
        return this
    }

    // Navigation method that returns the next Page
    fun clickLogin(): HomePage {
        loginBtn.click()
        return HomePage(baseTest)
    }

    // Encapsulated test user login (matches your original startApp() logic)
    fun loginAsTestUser(): HomePage {
        return enterUsername("test_user")
            .enterPassword("test_pass")
            .clickLogin()
    }
}

HomePage (Main Navigation Hub)

class HomePage(private val baseTest: BaseTest) {
    private val settingsMenuBtn = baseTest.waitForElement(By.id("com.your.app:id/settings_menu"))
    private val profileBtn = baseTest.waitForElement(By.id("com.your.app:id/profile_btn"))

    // Navigation to Settings Page
    fun navigateToSettings(): SettingsPage {
        settingsMenuBtn.click()
        return SettingsPage(baseTest)
    }

    // Navigation to Profile Page (example of another flow)
    fun navigateToProfile(): ProfilePage {
        profileBtn.click()
        return ProfilePage(baseTest)
    }
}

Updated AppTest

open class AppTest : BaseTest() {
    fun startApp(): HomePage {
        // Launch the app (your existing logic)
        driver.launchApp()
        
        // Chain entry flow to return HomePage directly
        return SplashScreenPage(this)
            .waitAndProceedToLogin()
            .loginAsTestUser()
    }
}

Example Test Class (SettingsTest)

class SettingsTest : AppTest() {
    private lateinit var settingsPage: SettingsPage

    @Before
    fun setup() {
        // Replace getToUI() with clear navigation chain
        settingsPage = startApp()
            .navigateToSettings()
    }

    @Test
    fun testDarkModeToggle() {
        // Use the SettingsPage to interact with UI elements
        settingsPage.toggleDarkMode()
        assert(settingsPage.isDarkModeEnabled())
    }
}

Final Best Practices #

• Keep Page classes focused: Each Page should only handle elements and actions specific to that UI, plus navigation to directly related Pages.
• Avoid hardcoding test data in Pages: If you need test-specific inputs (like test user credentials), pass them as parameters to Page methods or use a test data helper class.
• Fluent interface for readability: Returning the same Page instance from action methods (like enterUsername()) makes test code more readable and maintainable.
• Never navigate in Page init: Page objects should be lightweight—they represent the current UI state, not trigger navigation to reach that state.

内容的提问来源于stack exchange，提问作者szaske