Unit testing στην ανάπτυξη εφαρμογών για κινητά: τι είναι, μέθοδοι και frameworks

Τι είναι το unit testing;

Το unit testing είναι η διαδικασία ελέγχου μεμονωμένων μονάδων (unit) του πηγαίου κώδικα — συναρτήσεων, μεθόδων, κλάσεων — σε απομόνωση από το υπόλοιπο πρόγραμμα. Κάθε test εκτελεί ένα συγκεκριμένο σενάριο χρήσης του module και ελέγχει αν το αποτέλεσμα αντιστοιχεί στο αναμενόμενο. Τα unit tests γράφονται στην ίδια γλώσσα προγραμματισμού με τον βασικό κώδικα και εκτελούνται αυτόματα στο περιβάλλον ανάπτυξης ή στο CI/CD pipeline. Σε αντίθεση με τα integration tests, τα unit tests δεν αλληλεπιδρούν με πραγματικές βάσεις δεδομένων, σύστημα αρχείων ή δικτυακές υπηρεσίες.

Γιατί χρειαζόμαστε unit tests;

Ο κύριος στόχος είναι η γρήγορη ανατροφοδότηση σχετικά με την ορθότητα του κώδικα μετά από αλλαγές. Αν ένας προγραμματιστής κάνει refactor σε μια μέθοδο, το σύνολο των unit tests επιβεβαιώνει ότι η συμπεριφορά δεν έχει σπάσει. Σύμφωνα με το Google Testing Blog (2025), τα projects με κάλυψη unit tests άνω του 60% έχουν 2,5 φορές λιγότερα περιστατικά σε παραγωγή. Πρόσθετα πλεονεκτήματα: τεκμηρίωση κώδικα (τα tests δείχνουν πώς να χρησιμοποιείται το API), απλοποίηση του refactoring (η υλοποίηση μπορεί να αλλάξει διατηρώντας τη συμπεριφορά) και γρήγορη διάγνωση regressions.

Τι θεωρείται unit test;

Δεν είναι κάθε αυτόματο test unit test. Κριτήρια: ελέγχεται ένα module (κλάση ή συνάρτηση), οι εξωτερικές εξαρτήσεις αντικαθίστανται με mocks ή stubs, το test εκτελείται σε χιλιοστά του δευτερολέπτου, δεν απαιτεί εκκίνηση server ή βάσης δεδομένων. Ένα test που προσπελαύνει πραγματική βάση δεδομένων είναι integration test. Ένα test που ανοίγει browser είναι E2E test. Η κατανόηση των ορίων μεταξύ των τύπων tests είναι σημαντική για τη σωστή κατανομή προσπαθειών στην πυραμίδα testing.

Οι αρχές FIRST και η δομή AAA

Τα ποιοτικά unit tests ακολουθούν τις αρχές FIRST, όπως διατυπώθηκαν από τον Robert C. Martin. Κάθε test πρέπει να είναι Fast (γρήγορο — χιλιοστά δευτερολέπτου), Isolated (απομονωμένο — δεν εξαρτάται από άλλα tests), Repeatable (αναπαραγώγιμο — ίδιο αποτέλεσμα σε οποιοδήποτε μηχάνημα), Self-validating (αυτοεπαληθευόμενο — αποτέλεσμα “passed” ή “failed”, χωρίς χειροκίνητο έλεγχο) και Timely (έγκαιρο — γραμμένο πριν ή ταυτόχρονα με τον κώδικα). Η παραβίαση οποιασδήποτε αρχής μειώνει την αξία του test.

Δομή AAA (Arrange-Act-Assert)

Το τυπικό μοτίβο για τη σύνταξη unit tests. Arrange — προετοιμασία δεδομένων και εξαρτήσεων: δημιουργία αντικειμένων, ρύθμιση mocks, καθορισμός παραμέτρων εισόδου. Act — εκτέλεση της υπό δοκιμή ενέργειας: κλήση μεθόδου ή συνάρτησης. Assert — έλεγχος αποτελέσματος: σύγκριση πραγματικής τιμής με την αναμενόμενη. Ο διαχωρισμός σε τρία blocks κάνει το test αναγνώσιμο και κατανοητό. Αν το block Assert απαιτεί σύνθετη λογική, το test πιθανώς ελέγχει πάρα πολλά πράγματα ταυτόχρονα.

// Παράδειγμα unit test με το μοτίβο AAA σε Kotlin με JUnit 5
class CalculatorTest {

    private lateinit var calculator: Calculator

    @BeforeEach
    fun setUp() {
        // ARRANGE — δημιουργούμε το υπό δοκιμή αντικείμενο
        calculator = Calculator()
    }

    @Test
    fun addition_shouldReturnCorrectSum() {
        // ACT — εκτελούμε την ενέργεια
        val result = calculator.add(2, 3)

        // ASSERT — ελέγχουμε το αποτέλεσμα
        Assertions.assertEquals(5, result)
    }
}

Ονομασία tests

Το όνομα του test πρέπει να περιγράφει τι ελέγχεται και ποιο αποτέλεσμα αναμένεται. Μορφή: [methodName]_[scenario]_[expectedResult]. Παράδειγμα: calculateTotal_whenDiscountApplied_shouldReturnDiscountedTotal. Ένα καλό όνομα test αντικαθιστά το σχόλιο και σε περίπτωση αποτυχίας υποδεικνύει αμέσως ποια λειτουργικότητα έχει σπάσει. Αποφύγετε ονόματα όπως test1, checkSomething ή verify — δεν μεταφέρουν πληροφορία και δυσχεραίνουν τη διάγνωση.

Mocks, stubs και fakes: τι και πότε να χρησιμοποιείτε

Για την απομόνωση του υπό δοκιμή module από εξωτερικές εξαρτήσεις χρησιμοποιούνται test doubles. Κύριοι τύποι: mocks — ελέγχουν αν μια συγκεκριμένη μέθοδος κλήθηκε με τις σωστές παραμέτρους; stubs — επιστρέφουν προκαθορισμένες τιμές κατά την κλήση της μεθόδου; fakes — απλοποιημένη υλοποίηση ενός πραγματικού component (π.χ. InMemoryUserRepository αντί για UserRepository που λειτουργεί με DB). Η επιλογή εξαρτάται από το τι πρέπει να ελεγχθεί: κατάσταση (stub) ή αλληλεπίδραση (mock).

Mockito: παράδειγμα mocking σε Java/Kotlin

Το Mockito είναι το πιο δημοφιλές framework για mocking σε Java και Kotlin. Επιτρέπει τη δημιουργία mocks μέσω mock(), τη ρύθμιση επιστρεφόμενων τιμών μέσω when().thenReturn() και τον έλεγχο κλήσεων μέσω verify(). Οι σύγχρονες εκδόσεις του Mockito (5.x) υποστηρίζουν στατικά mocks (mockStatic) και απλοποιημένο συντακτικό μέσω BDDMockito (given-willReturn). Σημαντικός κανόνας: μην κάνετε mock σε ό,τι δεν είναι δικό σας — μην δημιουργείτε mocks για value objects και τυπικές βιβλιοθήκες.

// Παράδειγμα unit test με Mockito σε Kotlin
class OrderServiceTest {

    @Mock
    private lateinit var paymentGateway: PaymentGateway

    @Mock
    private lateinit var userRepository: UserRepository

    private lateinit var orderService: OrderService

    @BeforeEach
    fun init() {
        MockitoAnnotations.openMocks(this)
        orderService = OrderService(paymentGateway, userRepository)
    }

    @Test
    fun processOrder_whenPaymentFails_shouldThrowException() {
        // given
        val user = User(id = 1, balance = 100.0)
        val order = Order(amount = 200.0)
        Mockito.`when`(paymentGateway.charge(any())).thenReturn(false)
        Mockito.`when`(userRepository.findById(1)).thenReturn(user)

        // when & then
        assert Throws<PaymentException> {
            orderService.processOrder(user.id, order)
        }

        // verify
        Mockito.verify(paymentGateway).charge(any())
    }
}

TDD: ανάπτυξη μέσω testing

TDD (Test-Driven Development) — μεθοδολογία κατά την οποία το test γράφεται πριν από την υλοποίηση του κώδικα. Ο κύκλος “Red-Green-Refactor”: γράψτε ένα test που αποτυγχάνει (Red), γράψτε τον ελάχιστο κώδικα για να περάσει το test (Green), βελτιώστε τον κώδικα χωρίς να αλλάξετε τη συμπεριφορά (Refactor). Το TDD εγγυάται ότι όλος ο κώδικας καλύπτεται από tests (coverage = 100% για τη γραμμένη λειτουργικότητα) και ότι ο κώδικας είναι testable — αν ο κώδικας είναι δύσκολο να ελεγχθεί, σημαίνει ότι η αρχιτεκτονική χρήζει βελτίωσης.

Πλεονεκτήματα του TDD

Σύμφωνα με τη διαχρονική μελέτη της IBM (2006-2026), οι ομάδες που χρησιμοποιούν TDD έχουν 40-80% λιγότερα σφάλματα σε παραγωγή σε σύγκριση με ομάδες που γράφουν tests μετά τον κώδικα. Το TDD βελτιώνει επίσης την αρχιτεκτονική: ο προγραμματιστής αναγκάζεται να σκεφτεί τον σχεδιασμό του API πριν από την υλοποίηση, οδηγώντας σε χαλαρή σύζευξη (loose coupling) και υψηλή συνοχή (high cohesion). Ένα πρόσθετο αποτέλεσμα είναι η τεκμηρίωση μέσω ζωντανού κώδικα: τα tests λειτουργούν ως προδιαγραφή συμπεριφοράς του module, η οποία είναι πάντα ενημερωμένη.

Πότε δεν είναι κατάλληλο το TDD;

Το TDD δεν είναι πάντα βέλτιστο. Τα UI components είναι δύσκολο να ελεγχθούν σε απομόνωση — γι' αυτά είναι πιο αποτελεσματικά τα snapshot tests ή το visual regression testing (Percy, Chromatic). Η δημιουργία πρωτοτύπων και η έρευνα (spike solutions) δεν απαιτούν tests. Ο legacy κώδικας χωρίς tests είναι δύσκολο να καλυφθεί μέσω TDD — εδώ χρειάζονται πρώτα characterization tests (tests που καταγράφουν την τρέχουσα συμπεριφορά πριν από το refactoring). Σε αυτές τις περιπτώσεις το TDD δεν ακυρώνεται εντελώς, αλλά προσαρμόζεται — γράφονται tests για την υπό αλλαγή λειτουργικότητα, όχι για ολόκληρο τον legacy κώδικα.

Unit testing σε mobile εφαρμογές

Η mobile ανάπτυξη έχει τις ιδιαιτερότητές της: η επιχειρηματική λογική συχνά αναμειγνύεται με τον UI κώδικα (Activity, ViewController, ViewModel), γεγονός που περιπλέκει το unit testing. Η βέλτιστη πρακτική είναι λεπτά Views, παχιά ViewModels: μεταφέρετε όλη τη λογική από τα UI components σε ξεχωριστές κλάσεις (UseCase, Repository, ViewModel) που είναι εύκολο να ελεγχθούν χωρίς emulator. Για Android και iOS υπάρχουν native frameworks unit testing που λειτουργούν σε JVM/Native χωρίς εκκίνηση συσκευής.

Unit tests σε Android (JUnit + Mockito/Robolectric)

Τα Android unit tests εκτελούνται σε τοπικό JVM χωρίς emulator, εξασφαλίζοντας ταχύτητα εκτέλεσης — ένα τυπικό test διαρκεί λιγότερο από 100ms. Το JUnit 5 είναι ο κύριος runner. Για ViewModel tests χρησιμοποιήστε το kotlinx-coroutines-test για τη δοκιμή coroutines και το Turbine για τη δοκιμή StateFlow. Το Robolectric επιτρέπει τη δοκιμή Android-εξαρτώμενων components (Context, Resources) χωρίς emulator, φορτώνοντας shadow classes. Για Compose tests χρησιμοποιήστε το Compose UI Test — αλλά αυτό είναι ήδη UI test, όχι unit.

Unit tests σε iOS (XCTest + Quick/Nimble)

Τα iOS unit tests γράφονται σε Swift με XCTest (ενσωματωμένο στο Xcode). Quick + Nimble — BDD frameworks για πιο ευανάγνωστα tests (describe/context/it). Για mocking χρησιμοποιήστε το Cuckoo (παραγωγή mocks) ή το SwiftyMocky. Το Swift υποστηρίζει protocols και dependency injection, διευκολύνοντας την αντικατάσταση εξαρτήσεων. Σημαντικό σημείο: τα iOS unit tests εκτελούνται στον simulator macOS, όχι σε πραγματική συσκευή. Tests που απαιτούν hardware λειτουργίες (κάμερα, Bluetooth) είναι integration tests.

Unit tests σε Flutter (flutter_test + Mockito)

Τα Flutter unit tests χρησιμοποιούν το πακέτο flutter_test και εκτελούνται σε Dart VM χωρίς emulator. Για mocking — το πακέτο mockito με code generator (build_runner). Τα widget tests (στο ίδιο πακέτο) δοκιμάζουν μεμονωμένα widgets, αλλά απαιτούν rendering και είναι πιο αργά — χρησιμοποιήστε τα μόνο για έλεγχο UI λογικής. Η καθαρή Dart λογική (models, repositories, blocs) δοκιμάζεται ως συνήθη Dart tests χωρίς εισαγωγή του flutter_test.

// Παράδειγμα unit test σε Flutter με mockito
import 'package:flutter_test/flutter_test.dart';
import 'package:mockito/mockito.dart';
import 'package:mockito/annotations.dart';

@GenerateMocks([ApiClient])
import 'user_repository_test.mocks.dart';

void main() {
    late MockApiClient mockApi;
    late UserRepository repository;

    setUp(() {
        mockApi = MockApiClient();
        repository = UserRepository(mockApi);
    });

    test('fetchUser returns user when API succeeds', () async {
        // Προετοιμασία
        final expectedUser = User(id: 1, name: 'Test');
        when(mockApi.getUser(1))
            .thenAnswer((_) async => expectedUser);

        // Εκτέλεση
        final result = await repository.fetchUser(1);

        // Έλεγχος
        expect(result, expectedUser);
        verify(mockApi.getUser(1)).called(1);
    });
}

Βέλτιστες πρακτικές και τυπικά λάθη

Το αποτελεσματικό unit testing απαιτεί πειθαρχία. Ο βασικός κανόνας: δοκιμάζετε τη συμπεριφορά, όχι την υλοποίηση. Το test δεν πρέπει να γνωρίζει πώς υλοποιείται το module εσωτερικά (ποιες ιδιωτικές μέθοδοι καλούνται, με ποια σειρά). Αν το test είναι δεμένο με την υλοποίηση, σπάει σε κάθε refactoring και χάνει την αξία του. Το test ελέγχει το συμβόλαιο: με είσοδο X πρέπει να υπάρχει έξοδος Y. Εξαίρεση αποτελούν τα tests για αλγόριθμους κρίσιμης απόδοσης, όπου η σειρά κλήσεων είναι σημαντική.

• Μία επαλήθευση ανά test — ένα assert ή μία ομάδα συσχετισμένων asserts ανά λογική επαλήθευση
• Αποφύγετε την επανάληψη — χρησιμοποιήστε @BeforeEach / setUp για κοινή αρχικοποίηση, parameterized tests για διαφορετικά δεδομένα εισόδου
• Μην ελέγχετε ιδιωτικές μεθόδους — δοκιμάστε μέσω του δημόσιου API. Αν μια ιδιωτική μέθοδος δεν καλύπτεται, σημαίνει ότι η λογική της δεν είναι ορατή από έξω
• Καλύψτε ακραίες περιπτώσεις — κενές συλλογές, null/undefined, αρνητικοί αριθμοί, μέγιστες τιμές
• Μη χρησιμοποιείτε Thread.sleep στα tests — κάνει τα tests αργά και ασταθή. Χρησιμοποιήστε test timeouts και coroutines

Ποιο coverage θεωρείται επαρκές;

Το 100% coverage είναι ανέφικτος και μη αναγκαίος στόχος. Σύμφωνα με το Google Testing Blog (2025), το βέλτιστο επίπεδο κάλυψης για unit tests είναι 70-80% των γραμμών κώδικα. Το 100% coverage συχνά επιτυγχάνεται μέσω δοκιμής getters, setters και constructors, που δεν προσφέρει αξία. Εστιάστε στην κρίσιμη επιχειρηματική λογική: σύνθετους υπολογισμούς, επικύρωση, διαχείριση σφαλμάτων, ακραίες περιπτώσεις. Χρησιμοποιήστε JaCoCo (Java), Coverage.py (Python), Istanbul (JS) για μέτρηση και ρυθμίστε ένα όριο στο CI — αποτυχία build σε coverage κάτω από 60%.

CI/CD και unit tests

Τα unit tests είναι το πρώτο στάδιο κάθε CI/CD pipeline. Εκτελούνται σε κάθε push στο repository, πριν από το build και το deploy. Ο μέσος χρόνος εκτέλεσης των unit tests σε ένα project δεν πρέπει να υπερβαίνει τα 5 λεπτά — αν είναι μεγαλύτερος, τα tests παύουν να είναι “γρήγορα” και οι προγραμματιστές σταματούν να τα εκτελούν τοπικά. Διαχωρίστε τα tests σε γρήγορα (unit) και αργά (integration) και εκτελέστε τα σε διαφορετικά στάδια του pipeline. Χρησιμοποιήστε παράλληλη εκτέλεση και fail-fast για επιτάχυνση.