Δοκιμές UI σε εφαρμογές κινητών: τι είναι, είδη και πώς διεξάγονται

Τι είναι οι δοκιμές UI;

Οι δοκιμές UI είναι ένα είδος αυτοματοποιημένου ελέγχου όπου ο κώδικας δοκιμής αλληλεπιδρά με τη γραφική διεπαφή της εφαρμογής όπως θα έκανε ένας πραγματικός χρήστης. Η δοκιμή βρίσκει ένα στοιχείο στην οθόνη — κουμπί, πεδίο κειμένου, λίστα — εκτελεί μια ενέργεια σε αυτό και ελέγχει την αναμενόμενη απόκριση της διεπαφής. Για παράδειγμα, μετά την εισαγωγή ενός λανθασμένου κωδικού πρόσβασης, η δοκιμή UI ελέγχει ότι εμφανίστηκε μήνυμα σφάλματος με το σωστό κείμενο.

Η κύρια διαφορά των δοκιμών UI από άλλα είδη αυτοματοποίησης είναι ότι λειτουργούν μέσω του επιπέδου προσβασιμότητας του λειτουργικού συστήματος και όχι μέσω εσωτερικών API της εφαρμογής. Αυτό σημαίνει ότι οι δοκιμές UI βλέπουν τη διεπαφή ακριβώς όπως ο χρήστης και το σύστημα ανάγνωσης οθόνης. Χάρη σε αυτό, οι δοκιμές UI ελέγχουν όχι μόνο τη λειτουργικότητα αλλά και την προσβασιμότητα των στοιχείων — συμμόρφωση με τις απαιτήσεις WCAG.

Σύμφωνα με έρευνα του JetBrains Developer Ecosystem 2023, το 58% των ομάδων κινητών χρησιμοποιούν δοκιμές UI στη γραμμή CI/CD τους. Η μέση κάλυψη δοκιμών UI σε εμπορικά έργα είναι 30–40% των οθονών της εφαρμογής. Παράλληλα, τα έργα με δοκιμές UI λαμβάνουν 25% λιγότερες αρνητικές κριτικές στα καταστήματα εφαρμογών που σχετίζονται με σφάλματα διεπαφής.

Πώς διαφέρουν οι δοκιμές UI από τις μοναδιαίες

Η κύρια διαφορά μεταξύ δοκιμών UI και μοναδιαίων δοκιμών είναι το επίπεδο αφαίρεσης. Οι μοναδιαίες δοκιμές λειτουργούν με μεμονωμένες κλάσεις και συναρτήσεις, απομονωμένες από το πλαίσιο Android ή iOS. Εκτελούνται σε JVM (για Android) χωρίς εκκίνηση εξομοιωτή και διαρκούν χιλιοστά του δευτερολέπτου. Οι δοκιμές UI εκτελούνται σε πραγματική συσκευή ή εξομοιωτή, αλληλεπιδρούν με υπηρεσίες συστήματος και απαιτούν δευτερόλεπτα ή λεπτά για ένα σενάριο.

Διαφέρει επίσης το κοινό-στόχος των δοκιμών. Οι δοκιμές UI ελέγχουν ολοκληρωμένα σενάρια χρήστη — εγγραφή, ολοκλήρωση παραγγελίας, αναζήτηση. Οι μοναδιαίες δοκιμές καλύπτουν την επιχειρηματική λογική: υπολογισμούς, επικύρωση, μετασχηματισμό δεδομένων. Μια δοκιμή UI δεν ελέγχει την ορθότητα του υπολογισμού φόρου — ελέγχει ότι το τελικό ποσό εμφανίζεται στην οθόνη. Ο ίδιος ο υπολογισμός ελέγχεται από μοναδιαία δοκιμή.

Σύμφωνα με το Google Testing Blog (2020), η βέλτιστη αναλογία δοκιμών σε ένα έργο ακολουθεί τον κανόνα της πυραμίδας δοκιμών: 70% μοναδιαίες δοκιμές, 20% ενσωματωτικές και 10% δοκιμές UI. Η παραβίαση αυτής της αναλογίας υπέρ των δοκιμών UI οδηγεί σε αύξηση του χρόνου εκτέλεσης και ευθραυστότητα του συνόλου δοκιμών, καθώς οι δοκιμές UI είναι ευαίσθητες σε αλλαγές στη διάταξη των οθονών.

Πλαίσια για δοκιμές UI

Για Android, το κυρίαρχο πλαίσιο είναι το Espresso — μια βιβλιοθήκη της Google, ενσωματωμένη στο AndroidX Test. Το Espresso συγχρονίζεται αυτόματα με το νήμα UI, περιμένοντας την ολοκλήρωση κινούμενων γραφικών και εργασιών παρασκηνίου πριν εκτελέσει τον επόμενο έλεγχο. Για το Jetpack Compose χρησιμοποιείται η επέκταση Compose UI Test, η οποία λειτουργεί μέσω σημασιολογικών κόμβων αντί για παραδοσιακά αναγνωριστικά προβολής.

Για iOS, το κύριο εργαλείο είναι το XCUITest, το οποίο αποτελεί μέρος του Xcode. Οι δοκιμές γράφονται σε Swift και χρησιμοποιούν αναγνωριστικά προσβασιμότητας για την εύρεση στοιχείων. Το XCUITest υποστηρίζει εγγραφή δοκιμών μέσω λειτουργίας εγγραφής και ενσωμάτωση με συστήματα CI μέσω xcodebuild. Για έργα πολλαπλών πλατφορμών χρησιμοποιείται το Appium, το οποίο βασίζεται στο πρωτόκολλο WebDriver και επιτρέπει την εκτέλεση των ίδιων δοκιμών σε Android και iOS με ελάχιστες αλλαγές στον κώδικα.

Espresso και Compose UI Test

Το Espresso λειτουργεί με το παραδοσιακό σύστημα View μέσω onView και αναγνωριστικών πόρων id. Το Compose UI Test χρησιμοποιεί ένα σημασιολογικό επίπεδο, καθιστώντας τις δοκιμές λιγότερο εξαρτημένες από την ιεραρχία των προβολών. Για παράδειγμα, αναζήτηση κουμπιού στο Espresso: onView(withId(R.id.submit)), στο Compose: onNodeWithTag("submit"). Οι δοκιμές Compose χειρίζονται αυτόματα την ανασύνθεση και δεν απαιτούν ρητές αναμονές για κατάσταση αδράνειας.

XCUITest για iOS

Το XCUITest χρησιμοποιεί το XCUIApplication ως σημείο εισόδου. Κάθε στοιχείο διεπαφής αναζητείται μέσω ιδιοτήτων προσβασιμότητας: accessibilityIdentifier για προγραμματική πρόσβαση και accessibilityLabel για VoiceOver. Το πλαίσιο υποστηρίζει εγγραφή δοκιμών μέσω της λειτουργίας εγγραφής του Xcode — ο προγραμματιστής εκτελεί ενέργειες στον εξομοιωτή και το Xcode παράγει τον κώδικα δοκιμής. Οι έτοιμες δοκιμές εκτελούνται μέσω xcodebuild test.

Λύσεις πολλαπλών πλατφορμών

Το Appium βασίζεται στο πρωτόκολλο WebDriver και υποστηρίζει οποιαδήποτε γλώσσα: Java, Python, JavaScript. Για την εύρεση στοιχείων χρησιμοποιούνται στρατηγικές id, xpath, class name και accessibility id. Το Appium απαιτεί εγκατάσταση διακομιστή και ρύθμιση Desired Capabilities — platformName, deviceName, appPackage. Μια εναλλακτική είναι το Maestro, το οποίο χρησιμοποιεί σενάρια YAML και δεν απαιτεί μεταγλώττιση κώδικα δοκιμής.

• Espresso — onView(withId(R.id.button)).perform(click()).check(matches(isDisplayed()))
• XCUITest — app.buttons["loginButton"].tap(); XCTAssertTrue(app.staticTexts["welcome"].exists)
• Appium — driver.findElement(By.id("com.example:id/button")).click()
• Detox — πλαίσιο από τη Wix για React Native, που συγχρονίζεται με το νήμα JS
• Maestro — σύγχρονο εργαλείο με σενάρια YAML, που δεν απαιτεί σύνταξη κώδικα

Παραδείγματα κώδικα για δοκιμές UI

Ας εξετάσουμε δοκιμές UI για το ίδιο σενάριο — είσοδο στην εφαρμογή — σε τρία διαφορετικά πλαίσια: Espresso για Android, XCUITest για iOS και Appium για προσέγγιση πολλαπλών πλατφορμών. Σενάριο: εισαγωγή ονόματος χρήστη και κωδικού πρόσβασης, πάτημα κουμπιού εισόδου, έλεγχος εμφάνισης μηνύματος καλωσορίσματος.

Android: Espresso

Η δοκιμή σε Espresso χρησιμοποιεί onView για εύρεση στοιχείου κατά αναγνωριστικό και perform για εκτέλεση ενέργειας. Η μέθοδος check με το matcher isDisplayed επιβεβαιώνει ότι το στοιχείο είναι ορατό στην οθόνη.

@RunWith(AndroidJUnit4::class)
class LoginUiTest {

    @Rule
    @JvmField
    val composeTestRule = createComposeRule()

    @Test
    fun login_withValidCredentials_showsWelcome() {
        composeTestRule
            .onNodeWithTag("emailField")
            .performTextInput("user@example.com")
        composeTestRule
            .onNodeWithTag("passwordField")
            .performTextInput("secret123")
        composeTestRule
            .onNodeWithTag("loginButton")
            .performClick()
        composeTestRule
            .onNodeWithText("Καλώς ήρθατε, Χρήστη!")
            .assertIsDisplayed()
    }
}

iOS: XCUITest

Το XCUITest χρησιμοποιεί το XCUIApplication για πρόσβαση σε στοιχεία διεπαφής μέσω αναγνωριστικών προσβασιμότητας. Οι μέθοδοι tap() και exists παρέχουν αλληλεπίδραση και έλεγχο.

class LoginUITests: XCTestCase {
    let app = XCUIApplication()

    override func setUp() {
        continueAfterFailure = false
        app.launch()
    }

    func testLogin_withValidCredentials_showsWelcome() {
        app.textFields["emailField"].tap()
        app.textFields["emailField"].typeText("user@example.com")
        app.secureTextFields["passwordField"].tap()
        app.secureTextFields["passwordField"].typeText("secret123")
        app.buttons["loginButton"].tap()
        XCTAssertTrue(app.staticTexts["Welcome, User!"].exists)
    }
}

Βέλτιστες πρακτικές δοκιμών UI

Η πρώτη αρχή — χρησιμοποιήστε αναγνωριστικά προσβασιμότητας αντί για ετικέτες κειμένου για την εύρεση στοιχείων. Το κείμενο ενός κουμπιού μπορεί να αλλάξει κατά την τοπικοποίηση, ενώ το αναγνωριστικό παραμένει σταθερό. Στο Android αυτή είναι η ιδιότητα contentDescription, στο iOS — accessibilityIdentifier. Αυτή η προσέγγιση καθιστά τις δοκιμές ανεξάρτητες από τη γλώσσα της διεπαφής και μειώνει το κόστος συντήρησης κατά την αλλαγή κειμένων.

Αποφύγετε τα sleep() και σταθερές καθυστερήσεις — χρησιμοποιήστε ενσωματωμένους μηχανισμούς αναμονής του πλαισίου. Το Espresso περιμένει αυτόματα την ολοκλήρωση κινούμενων γραφικών και εργασιών παρασκηνίου. Το XCUITest παρέχει XCTAssertTrue με χρονικό όριο. Οι ρητές παύσεις καθιστούν τις δοκιμές πιο αργές και ασταθείς, ειδικά σε αργές συσκευές σε περιβάλλον CI.

Ομαδοποιήστε τις δοκιμές κατά κρισιμότητα: οι δοκιμές smoke (3–5 βασικά σενάρια) εκτελούνται σε κάθε commit, το πλήρες σύνολο δοκιμών UI — πριν από την κυκλοφορία. Σύμφωνα με το Google Testing Blog (2022), οι δοκιμές UI που διαρκούν περισσότερο από 30 λεπτά στο CI μειώνουν τη συχνότητα εκτέλεσης κατά 40%, μειώνοντας την αποτελεσματικότητά τους ως εργαλείο έγκαιρης ανίχνευσης παλινδρομήσεων.

Περιορισμοί δοκιμών UI και πώς να τους παρακάμψετε

Οι δοκιμές UI έχουν μια σειρά περιορισμών. Ευαισθησία σε αλλαγές διάταξης: αλλαγή αναγνωριστικού, ιεραρχίας ή τύπου στοιχείου σπάει τη δοκιμή ακόμα και όταν η λειτουργικότητα παραμένει ίδια. Λύση — χρήση του προτύπου Page Object, το οποίο συγκεντρώνει τους επιλογείς στοιχείων σε ξεχωριστές κλάσεις. Κατά την αλλαγή διάταξης διορθώνεται ένα αρχείο Page Object και όχι δεκάδες δοκιμές.

Χρόνος εκτέλεσης: η εκτέλεση σε πραγματική συσκευή ή εξομοιωτή διαρκεί 10–50 φορές περισσότερο από μια μοναδιαία δοκιμή. Λύση — εκτέλεση δοκιμών UI παράλληλα σε πολλές συσκευές μέσω Firebase Test Lab ή AWS Device Farm. Αστάθεια (flakiness) — συχνό πρόβλημα εκτελέσεων CI, που προκαλείται από κινούμενα γραφικά, καθυστερήσεις δικτύου ή κατάσταση εξομοιωτή. Για την αντιμετώπιση της αστάθειας χρησιμοποιούνται αυτόματες επαναλήψεις αποτυχημένων δοκιμών και αναλυτική σταθερότητα κάθε σεναρίου δοκιμής.