TDD: τι είναι, αρχές δοκιμών και μεθοδολογία

Τι είναι το TDD;

Test-Driven Development — είναι μια πρακτική ανάπτυξης λογισμικού όπου τα αυτοματοποιημένα τεστ καθορίζουν τη γραφή κώδικα παραγωγής. Σε αντίθεση με την παραδοσιακή προσέγγιση, όπου ο κώδικας γράφεται και στη συνέχεια δοκιμάζεται, το TDD αντιστρέφει τη σειρά: πρώτα γράφεται το τεστ, μετά ο κώδικας που περνά αυτό το τεστ.

Ιδρυτής του TDD θεωρείται ο Kent Beck, ο οποίος διατύπωσε αυτή την πρακτική στα τέλη της δεκαετίας του 1990 στο πλαίσιο της μεθοδολογίας Extreme Programming (XP). Στο βιβλίο “Test-Driven Development: By Example” (2002) ο Beck περιέγραψε πέντε κανόνες TDD που έγιναν κανονικοί: γράψε τεστ πριν από τον κώδικα παραγωγής, γράψε ακριβώς όσο κώδικα χρειάζεται για να περάσει το τεστ και αναδιάρθρωσε μετά από κάθε κύκλο.

Βασικές αρχές του TDD

Πρώτη αρχή — το τεστ καθορίζει τη διεπαφή. Ο προγραμματιστής αναγκάζεται να σκεφτεί πώς θα χρησιμοποιηθεί το στοιχείο πριν σκεφτεί πώς υλοποιείται. Αυτό διαμορφώνει ένα καθαρό API από την αρχή.

TDD ως τεχνική σχεδιασμού

Δεύτερη αρχή — ελάχιστη υλοποίηση. Όταν γραφτεί το τεστ, ο προγραμματιστής γράφει ακριβώς όσο κώδικα παραγωγής χρειάζεται για να το περάσει — ούτε γραμμή παραπάνω. Αυτό αποτρέπει την πρόωρη αφαίρεση και την υπερβολική πολυπλοκότητα που ο Martin Fowler ονομάζει Speculative Generality.

Διαφορά TDD από τη συνηθισμένη δοκιμή

Βασική διαφορά μεταξύ TDD και δοκιμής “εκ των υστέρων” — πειθαρχία σειράς. Στο TDD, το τεστ όχι μόνο ελέγχει τον κώδικα — καθοδηγεί τη δομή του. Σύμφωνα με έρευνα της Microsoft Research (Nagappan et al., 2008), οι ομάδες που εφαρμόζουν TDD παρουσιάζουν μείωση της πυκνότητας ελαττωμάτων κατά 40–90% σε σύγκριση με ομάδες που χρησιμοποιούν την παραδοσιακή προσέγγιση.

Ο κύκλος Red-Green-Refactor

Ο κύκλος Red-Green-Refactor — είναι μια τριών βημάτων ακολουθία που επαναλαμβάνεται για κάθε νέο τεστ. Red: γράψε ένα τεστ που αποτυγχάνει. Green: γράψε ελάχιστο κώδικα για να περάσει το τεστ. Refactor: βελτίωσε τον κώδικα χωρίς να αλλάξεις τη συμπεριφορά του.

Φάση Red: γράψιμο αποτυχημένου τεστ

Ο προγραμματιστής γράφει ένα τεστ που ελέγχει μια μη υλοποιημένη λειτουργικότητα. Σε αυτό το στάδιο το τεστ πρέπει να αποτύχει — αυτό επιβεβαιώνει ότι το τεστ πραγματικά ελέγχει κάτι. Στο περιβάλλον ανάπτυξης Android, το πλαίσιο JUnit 5 δείχνει κόκκινη ένδειξη για αποτυχημένα τεστ, που έδωσε το όνομα στη φάση.

class CalculatorTest {
    fun testAddition() {
        val result = Calculator().add(2, 3)
        Assertions.assertEquals(5, result)
    }
}

Φάση Green: ελάχιστη υλοποίηση

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

class Calculator {
    fun add(a: Int, b: Int): Int {
        return a + b
    }
}

Φάση Refactor: βελτίωση χωρίς ρίσκο

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

Πλεονεκτήματα του TDD στην κινητή ανάπτυξη

Η εφαρμογή TDD σε κινητά έργα προσφέρει μετρήσιμα πλεονεκτήματα, επιβεβαιωμένα τόσο από ακαδημαϊκές έρευνες όσο και από την πρακτική κορυφαίων στούντιο ανάπτυξης.

Μείωση πυκνότητας ελαττωμάτων

Έρευνα της IBM (Bhat & Nagappan, 2006) σε τέσσερα βιομηχανικά έργα έδειξε ότι οι ομάδες που χρησιμοποιούν TDD κάνουν 40% λιγότερα ελαττώματα σε σύγκριση με παρόμοιες ομάδες που εργάζονται παραδοσιακά. Για την κινητή ανάπτυξη, όπου το κόστος επιδιόρθωσης σφάλματος μετά την κυκλοφορία στο Google Play είναι σημαντικά υψηλότερο από ό,τι στο στάδιο γραφής κώδικα, αυτή η μετρική είναι κρίσιμη.

Τεκμηρίωση κώδικα μέσω τεστ

Τα τεστ που γράφονται σύμφωνα με TDD χρησιμεύουν ως ζωντανή τεκμηρίωση του API. Ο προγραμματιστής που έρχεται στο έργο μπορεί να διαβάσει τα τεστ και να καταλάβει πώς πρέπει να χρησιμοποιείται κάθε στοιχείο. Αυτό είναι ιδιαίτερα πολύτιμο σε συνθήκες υψηλής κινητικότητας της ομάδας — ένα τυπικό πρόβλημα των κινητών στούντιο.

Σίγουρη αναδιάρθρωση

Κάλυψη κώδικα από τεστ που ξεπερνά το 90% επιτρέπει στους προγραμματιστές να πραγματοποιούν αναδιάρθρωση χωρίς φόβο να σπάσουν κάτι. Η Google στο βιβλίο της “Software Engineering at Google” (2020) αποκαλεί την κάλυψη τεστ τον βασικό παράγοντα που επιτρέπει τη διατήρηση της βάσης κώδικα καθαρής σε έργα με εκατομμύρια γραμμές κώδικα.

Εργαλεία και πλαίσια για TDD

Το οικοσύστημα TDD στην κινητή ανάπτυξη περιλαμβάνει εργαλεία για δοκιμές μονάδας, mocking και έλεγχο στοιχείων UI — τόσο για Android όσο και για iOS.

Επιλογή πλαισίου για Android

Για έργα Android σε Kotlin, η τυπική στοίβα περιλαμβάνει JUnit 5 + MockK. Το MockK προτιμάται έναντι του Mockito επειδή υποστηρίζει λειτουργίες πρώτης τάξης Kotlin — sealed class, coroutine και suspend-συναρτήσεις χωρίς πρόσθετη παραμετροποίηση.

Εργαλεία για iOS

Στην ανάπτυξη iOS, το TDD υλοποιείται μέσω XCTest — του ενσωματωμένου πλαισίου της Apple που παρέχει ισχυρισμούς, τάξεις δοκιμών και ενσωμάτωση με CI/CD μέσω Xcode Server ή GitHub Actions. Για mocking στο iOS χρησιμοποιούνται οι βιβλιοθήκες Cuckoo και OHHTTPStubs.

Παραδείγματα κώδικα TDD σε Kotlin

Ας εξετάσουμε ένα πραγματικό σενάριο TDD σε Kotlin για Android — δοκιμή ενός αποθετηρίου χρηστών. Πρώτα γράφουμε το τεστ, στη συνέχεια — την υλοποίηση που περνά αυτό το τεστ.

Βήμα 1: τεστ για UserRepository

class UserRepositoryTest {
    private val api = mockk<UserApi>()
    private val dao = mockk<UserDao>()
    private val repo = UserRepository(api, dao)

    fun `when api returns user then cache and emit`() = runTest {
        val user = User(1, "Alice")
        coEvery { api.getUser(1) } returns user
        every { dao.insert(user) } returns Unit

        val result = repo.getUser(1)

        assertEquals(user, result)
        verify { dao.insert(user) }
    }
}

Βήμα 2: ελάχιστη υλοποίηση

class UserRepository(
    private val api: UserApi,
    private val dao: UserDao
) {
    suspend fun getUser(id: Int): User {
        val user = api.getUser(id)
        dao.insert(user)
        return user
    }
}

Βήμα 3: τεστ για προσωρινή αποθήκευση με offline λειτουργία

Αφού περάσει το πρώτο τεστ, προσθέτουμε ένα δεύτερο — ελέγχουμε τη συμπεριφορά σε σφάλμα δικτύου. Τώρα το τεστ καθορίζει ότι όταν το API αποτυγχάνει, το αποθετήριο πρέπει να επιστρέψει δεδομένα από την προσωρινή μνήμη.

fun `when api fails then return cached user`() = runTest {
    val cached = User(1, "Cached Alice")
    coEvery { api.getUser(1) } throws IOException()
    every { dao.getById(1) } returns cached

    val result = repo.getUser(1)

    assertEquals(cached, result)
}

Συνηθισμένα λάθη κατά την εφαρμογή TDD

Η μετάβαση σε TDD συνοδεύεται από τυπικά λάθη που μπορούν να ακυρώσουν όλα τα πλεονεκτήματα της μεθοδολογίας. Η κατανόηση αυτών των παγίδων βοηθά τις ομάδες να εφαρμόζουν την πρακτική πιο αποτελεσματικά.

Πολύ μεγάλα τεστ

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

Αγνόηση της κόκκινης φάσης

Δεύτερο λάθος — γραφή τεστ που περνά από την αρχή. Αν το τεστ δεν ήταν κόκκινο τουλάχιστον μία φορά, δεν υπάρχει βεβαιότητα ότι ελέγχει κάτι. Κανόνας: ποτέ μην εμπιστεύεσαι ένα τεστ που δεν έχεις δει να αποτυγχάνει.

Παράλειψη αναδιάρθρωσης

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

• Δοκιμή υλοποίησης, όχι συμπεριφοράς — τα τεστ δένονται με λεπτομέρειες και σπάνε σε κάθε αναδιάρθρωση
• Έλλειψη τεστ για ακραίες περιπτώσεις — κενές λίστες, null τιμές, οριακές συνθήκες παραμένουν ακάλυπτες
• Αγνόηση ταχύτητας τεστ — αργά τεστ επιβραδύνουν τον βρόχο ανάδρασης και σκοτώνουν την πειθαρχία TDD