Τι είναι η Test Driven Development, προσεγγίσεις και πλεονεκτήματα

Το Test Driven Development (TDD) είναι μια προσέγγιση ανάπτυξης λογισμικού όπου αναπτύσσονται δοκιμαστικές περιπτώσεις για να προσδιοριστεί και να επικυρωθεί τι θα κάνει ο κώδικας.

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

Το Test Driven Development (TDD) ξεκινά με το σχεδιασμό και την ανάπτυξη δοκιμών για κάθε μικρό χαρακτηριστικό μιας εφαρμογής. Το πλαίσιο TDD καθοδηγεί τους προγραμματιστές να γράφουν νέο κώδικα μόνο εάν μια αυτοματοποιημένη δοκιμή έχει αποτύχει. Αυτή η προσέγγιση αποφεύγει την επικάλυψη κώδικα. Η ολοκληρωμένη ενότητα TDD είναι ανάπτυξη με γνώμονα τη δοκιμή.

Το Test Driven Development (TDD) δημιουργήθηκε ως μέρος ενός ευρύτερου παραδείγματος σχεδιασμού λογισμικού, γνωστό ως Extreme Programming (XP), το οποίο αποτελεί μέρος της μεθοδολογίας ανάπτυξης λογισμικού Agile.

Η απλή ιδέα του TDD είναι να γράφει και να διορθώνει αποτυχημένες δοκιμές πριν γράψει νέο κώδικα (πριν από την ανάπτυξη). Αυτό βοηθά στην αποφυγή διπλασιασμού του κώδικα καθώς γράφουμε έναν μικρό αριθμό κώδικα κάθε φορά για να περάσουμε δοκιμές. (Οι δοκιμές δεν είναι τίποτα άλλο από προϋποθέσεις που πρέπει να δοκιμάσουμε για να τις ικανοποιήσουμε).

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

Φάσεις της προσέγγισης TDD

Πριν γραφτεί οποιοσδήποτε νέος κώδικας, ο προγραμματιστής πρέπει πρώτα να δημιουργήσει μια δοκιμή μονάδας αποτυχίας. Στη συνέχεια, ο προγραμματιστής – ή ζευγάρι, ή όχλος – δημιουργεί ακριβώς αρκετό κώδικα για να ικανοποιήσει αυτή την απαίτηση. Μόλις περάσει η δοκιμή, ο προγραμματιστής μπορεί να αναδιαμορφώσει το έργο, κάνοντας βελτιώσεις χωρίς να αλλάξει τη συμπεριφορά.

Ενώ το TDD εστιάζει στις αλληλεπιδράσεις προγραμματιστών σε επίπεδο μονάδας, υπάρχουν και άλλες δημοφιλείς μέθοδοι, όπως η ανάπτυξη βάσει δοκιμής αποδοχής (ATDD) ή η ανάπτυξη βάσει συμπεριφοράς (BDD), οι οποίες επικεντρώνονται σε δοκιμές που μπορούν να γίνουν κατανοητές από τους πελάτες.

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

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

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

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

Αναμενόμενα οφέλη:

• σημαντικές μειώσεις στα ποσοστά ελαττωμάτων, με το κόστος μιας μέτριας αύξησης της αρχικής προσπάθειας ανάπτυξης
• Τα γενικά έξοδα αντισταθμίζονται περισσότερο από τη μείωση της προσπάθειας στα τελικά στάδια των έργων
• Το TDD οδηγεί σε καλύτερες σχεδιαστικές ιδιότητες στον κώδικα και, γενικότερα, σε υψηλότερο βαθμό "εσωτερικής" ή τεχνικής ποιότητας, για παράδειγμα βελτιώνοντας τις μετρήσεις συνοχής και σύζευξης

Μειονεκτήματα του TDD

Το TDD απαιτεί σημαντικές δεξιότητες για να είναι επιτυχές, ειδικά σε επίπεδο μονάδας. Πολλά παλαιού τύπου συστήματα απλά δεν έχουν κατασκευαστεί με γνώμονα τη δοκιμή μονάδων, γεγονός που καθιστά αδύνατη την απομόνωση στοιχείων για δοκιμή.

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

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

Κοινά λάθη:

• ξεχνώντας να κάνετε συχνά τεστ
• γράψτε πάρα πολλά τεστ ταυτόχρονα
• γράψτε δοκιμές που είναι πολύ μεγάλες ή ακαθάριστες
• γράφοντας υπερβολικά ασήμαντα τεστ, όπως η παράλειψη ισχυρισμών
• γράψτε δοκιμές για ασήμαντο κώδικα
• μερική υιοθέτηση: μόνο λίγοι προγραμματιστές σε μια ομάδα εργασίας χρησιμοποιούν το TDD
• κακή συντήρηση της σουίτας δοκιμών, που συνήθως οδηγεί σε μια δοκιμαστική σουίτα με απαγορευτικά μεγάλο χρόνο λειτουργίας
• η δοκιμαστική σουίτα εγκαταλείφθηκε (δηλαδή σπάνια ή ποτέ δεν εκτελείται) – μερικές φορές λόγω κακής συντήρησης, μερικές φορές λόγω εναλλαγής ομάδας

TDD φιλοσοφία

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

Τα διάφορα στάδια που εμπλέκονται σε έναν δοκιμαστικό κύκλο ανάπτυξης είναι:

• Προσθήκη δοκιμής: Κάθε νέα δυνατότητα στο TDD ξεκινά με μια δοκιμή που πρέπει να αποτύχει καθώς έχει τεθεί σε εφαρμογή πριν εφαρμοστεί οποιοδήποτε χαρακτηριστικό. Η προϋπόθεση για τη σύνταξη μιας δοκιμής πριν από την εφαρμογή της δυνατότητας είναι η σαφής κατανόηση της απαίτησης από τον προγραμματιστή. Αυτό επιτυγχάνεται μέσω ιστοριών χρηστών και περιπτώσεων χρήσης. Έτσι, ένας προγραμματιστής κατανοεί την απαίτηση πριν γράψει τον κώδικα του προγράμματος.
• Εκτελέστε όλες τις δοκιμές και ελέγξτε εάν ο νέος κωδικός αποτυγχάνει: αυτό διασφαλίζει ότι η ζώνη δοκιμής λειτουργεί σωστά και ότι η νέα δοκιμή δεν αποτυγχάνει χωρίς νέο κωδικό. Αυτό το βήμα επαληθεύει επίσης το τεστ και εξαλείφει την πιθανότητα να περνά πάντα το νέο τεστ.
• Write Code: Το επόμενο βήμα που ακολουθεί είναι η σύνταξη του κώδικα που διαγράφει τη δοκιμή. Ο νέος κώδικας δεν είναι τέλειος αλλά αργότερα τροποποιείται σύμφωνα με τις απαιτήσεις. Έχει σχεδιαστεί απλά για δοκιμή και δεν διαθέτει άλλα χαρακτηριστικά.
• Εκτέλεση αυτοματοποιημένων δοκιμών: Εάν κάθε περίπτωση δοκιμής που παράγεται περνάει εύκολα τη δοκιμή, σημαίνει ότι ο κώδικας πληροί όλες τις απαιτούμενες προδιαγραφές. Στη συνέχεια μπορεί να ξεκινήσει η τελική φάση του κύκλου.
• Κώδικας αναδιαμόρφωσης: Αυτό είναι παρόμοιο με την κατάργηση του διπλασιασμού. Μια ανακατασκευή δεν παραβιάζει καμία υπάρχουσα λειτουργικότητα και βοηθά στην εξάλειψη της διπλοτυπίας μεταξύ παραγωγής και κωδικού δοκιμής. Ο κωδικός καθαρίζεται τώρα όπως ζητήθηκε.
• Επανάληψη: Ο κύκλος επαναλαμβάνεται όπως στις προηγούμενες περιπτώσεις με νέο τεστ. Η βασική προϋπόθεση είναι το μέγεθος του βήματος να είναι μικρό, με περίπου 1-10 αλλαγές μεταξύ κάθε δοκιμαστικής εκτέλεσης. Εάν ο νέος κώδικας αποτύχει σε μια νέα δοκιμή, ο προγραμματιστής θα πρέπει να κάνει περισσότερο εντοπισμό σφαλμάτων. Η συνεχής ενοποίηση παρέχει αναστρέψιμα σημεία ελέγχου.

Ercole Palmeri