Γιατί η εξέλιξη της εξέλιξης (TDD) είναι ο καλύτερος τρόπος για την εύρωστη κωδικοποίηση.

Αρχικά, δοκιμάστε τις μονάδες εγγραφής και, στη συνέχεια, γράψτε τον κώδικα.

Συντελεστές εικόνας: Pexels.com

Πριν από μερικά χρόνια, όταν άκουσα για πρώτη φορά το "Test Driven Development", ήμουν σκεπτικός.

Η ίδια η ιδέα των "πρώτων δοκιμαστικών μονάδων εγγραφής, στη συνέχεια, να γράψω τον κώδικα" ήταν άσχημη για μένα.

Γιατί δεν θα ήταν; Γράψτε πρώτα τις δοκιμές της μονάδας σας; Ποιος θα έκανε ένα άγριο πράγμα σαν αυτό;

Ήταν όμως επαγγελματίας προγραμματιστής για 10 χρόνια μέχρι τότε και είχα δει τα πράγματα να έρχονται και να πάνε στον κλάδο. Ήξερα καλύτερα από το να απορρίψω κάτι από το χέρι, ειδικά όταν οι προγραμματιστές ήταν τόσο gung-ho για αυτό.

Συνεπώς, συμβουλεύτηκα έναν φίλο μου που μου έδειξε ένα βασικό παράδειγμα.

Αυτό το βασικό παράδειγμα έχει μια κλάση LCL_SUM με μια μέθοδο SUM. Η ευθύνη αυτής της μεθόδου είναι να προσθέσετε τους αριθμούς. Παίρνει έναν αριθμό ως παράμετρο εισαγωγής και στη συνέχεια το προσθέτει στον εαυτό της για να παραγάγει το αποτέλεσμα. Ας ονομάσουμε αυτή τη μέθοδο ως μέθοδο παραγωγής.

Ο κώδικας για την τάξη ήταν έτσι:

CLASS lcl_sum ΟΡΙΣΜΟΣ.
ΔΗΜΟΣΙΑ ΤΜΗΜΑ.
ΜΕΘΟΔΟΙ: ΕΙΣΑΓΩΓΗ ΑΝΤΙΣΥΜΒΑΛΛΟΝΤΩΝ iv_1 ΤΥΠΟΣ i
ΑΝΤΙΣΤΡΟΦΗ ΑΞΙΑ (rv_sum) ΤΥΠΟΣ i.
ENDCLASS. "Lcl_sum ΟΡΙΣΜΟΣ
*
ΑΡΧΗ ΤΗΣ ΕΠΙΛΟΓΗΣ.
* Τίποτα δεν υπάρχει ακόμα
*
*
CLASS lcl_sum ΕΦΑΡΜΟΓΗ.
ΜΕΘΟΔΟΣ SUM.
rv_sum = iv_1 * iv_1. "Εσκεμμένο λάθος (πολλαπλασιάζω αντί να προσθέσω)
ENDMETHOD. "άθροισμα
ENDCLASS. "Lcl_sum ΕΦΑΡΜΟΓΗ.

Ρύθμιση δοκιμαστικής κλάσης

Τώρα δημιουργήστε μια τάξη που λειτουργεί ως δοκιμαστική κλάση. Στο SAP θα πρέπει να προσθέσετε τη λέξη-κλειδί FOR TESTING κατά τον ορισμό της κλάσης. Αυτή η προσθήκη διαχωρίζει αυτή την κλάση από τον κώδικα παραγωγής.

CLASS lcl_test ΟΡΙΣΜΟΣ ΓΙΑ ΤΙΣ ΔΟΚΙΜΕΣ
ΔΗΜΟΣΙΑ ΤΜΗΜΑ.
ΜΕΘΟΔΟΙ: m_sum ΓΙΑ ΔΟΚΙΜΕΣ.
ENDCLASS. "Lcl_test ΟΡΙΣΜΟΣ
*
CLASS lcl_test ΕΦΑΡΜΟΓΗ.
METHOD m_sum.
ENDMETHOD. "M_sum
ENDCLASS. "Lcl_test ΕΦΑΡΜΟΓΗ

Εφαρμογή μεθόδου δοκιμής

Σε αυτή τη μέθοδο δοκιμής, αυτό που πρέπει να κάνετε είναι - Δοκιμάστε τον κώδικα παραγωγής. Έτσι, για να μπορέσετε να δοκιμάσετε τη μέθοδο SUM του LCL_SUM, θα χρειαστεί να προβάλετε μια αναφορά αντικειμένου στο LCL_SUM, καλέστε τη μέθοδο SUM που στέλνει την τιμή dummy.

Με βάση την τιμή dummy, η μέθοδος θα σας στείλει το αποτέλεσμα - το πραγματικό αποτέλεσμα από τη μέθοδο. Με βάση την τιμή Dummy, ξέρετε τι θα ήταν η αναμενόμενη αξία. Π.χ. Εάν περάσετε τον αριθμό 3 στη μέθοδο SUM, θα σας δώσει το αποτέλεσμα του 6 καθώς προσθέτει στο 3.

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

CLASS lcl_test ΕΦΑΡΜΟΓΗ.
METHOD m_sum.
ΔΕΔΟΜΕΝΑ: o_cut ΤΥΠΟΣ REF TO lcl_sum.
ΔΕΔΟΜΕΝΑ: lv_result ΤΥΠΟΣ i.
*
CREATE OBJECT o_cut.
lv_result = o_cut-> άθροισμα (3).
*
cl_aunit_assert => assert_equals (
EXP = 6
act = lv_result
msg = 'κάτι λάθος στην έξοδο'
).
ENDMETHOD. "M_sum
ENDCLASS. "Lcl_test ΕΦΑΡΜΟΓΗ

Αποτελέσματα δοκιμής μονάδας

Αυτό μου λέει ότι υπάρχει κάτι λάθος στην εφαρμογή της μεθόδου παραγωγής.

Ναι, αν κοιτάξετε προσεκτικά την εφαρμογή μεθόδου του SUM, έχω ένα τυπογραφικό λάθος - αντί να χρησιμοποιήσω την Summation, είχα χρησιμοποιήσει τον πολλαπλασιασμό. Έτσι, θα το διορθώσω και θα επαναλάβω τη δοκιμή για να την εκτελέσω με επιτυχία.

Ήμουν αγκιστρωμένος στο TDD. Το Flabbergasted θα ήταν η σωστή λέξη.

Αυτό που ήταν εκπληκτικό ήταν ο πολύ μειωμένος χρόνος του κύκλου ανάπτυξης και δοκιμών.

Είχα συνηθίσει να γράφω τον κώδικα για το καλύτερο μέρος μιας ώρας πριν προσπαθήσω να το συντάξω ή να τρέξω. Αλλά εδώ ο κώδικας εκτελείται και ελέγχεται κάθε 2 λεπτά περίπου.

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

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

Αυτό το μέτρο εμποδίζει τους προγραμματιστές να γράφουν περιττό κώδικα που δεν συμμορφώνεται με τη δεδομένη δοκιμή.

Και αυτή η ολοκληρωμένη προσέγγιση προσφέρει μια πολυάριθμη ωφέλεια στον κύριο του έργου.

Μπορείτε να διορθώσετε τον κακό κώδικα χωρίς να σπάσετε τίποτα.

Κάθε φορά που βλέπετε τον κακό κώδικα, στρέφετε τα μάτια σας, προσεύχεστε στο Θεό και εκφωνείτε μία από τις δύο δηλώσεις.

· "Αυτό είναι ένα χάος. Υποθέτω ότι πρέπει να το διορθώσω κάπως ".

· «Δεν το αγγίζω».

Σε κάθε περίπτωση, υπάρχει ένα στοιχείο φόβου. Στην πραγματικότητα, αβεβαιότητα.

Τι γίνεται αν ο κωδικός μου σπάσει την υπάρχουσα λειτουργικότητα;

Το TDD σας βοηθά ακριβώς να ξεπεράσετε αυτήν την αβεβαιότητα.

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

Και όσο πιο πολύ ο κώδικας σας, τόσο λιγότερη προσπάθεια πρέπει να κάνει η ομάδα σας για να προσθέσει νέα χαρακτηριστικά ή να τροποποιήσει το υπάρχον κωδικό.

Το TDD επιβάλλει την τεκμηρίωση.

Dick Brandon χτύπησε το κτύπημα στο νύχι, όταν παρατήρησε.

"Η τεκμηρίωση είναι σαν το φύλο. όταν είναι καλό, είναι πολύ, πολύ καλό και όταν είναι κακό, είναι καλύτερο από τίποτα. "

Η τεκμηρίωση είναι το καστορέλαιο του προγραμματισμού. Οι διευθυντές πιστεύουν ότι είναι καλό για τους προγραμματιστές και τους προγραμματιστές να το μισούν!

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

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

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

Το TDD βοηθά στην καλύτερη σχεδίαση

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

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

Αυτό δημιουργεί ένα καλύτερο, αποσυνδεδεμένο σχέδιο στο οποίο έχετε τον καλύτερο έλεγχο των πραγμάτων καθώς αναπτύσσεται ο κώδικας.

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

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

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

Τέλος, το TDD ακολουθεί τις καλύτερες πρακτικές κωδικοποίησης.

Το TDD προωθεί καλές αρχές κωδικοποίησης, συμπεριλαμβανομένων των DRY, KISS, YAGNI και SOLID.

Η αρχή DRY (Do not Repeat Yourself) λέει στους προγραμματιστές να αποφύγουν την επανάληψη του ίδιου κώδικα σε διαφορετικά μέρη του ίδιου συστήματος, γι 'αυτό και κάποιες φορές καλείται η αρχή DIE (Duplication Is Evil). Το DRY συνιστά στους προγραμματιστές να χρησιμοποιούν τάξεις και λειτουργίες για την ενσωμάτωση της λειτουργικότητας του συστήματος και τη διατήρηση ενός σταθερού κώδικα.

Η αρχή KISS (Keep it Simple, Stupid!) Συμβουλεύει τους προγραμματιστές να μην ανακαλύψουν τον τροχό, αλλά να χτίσουν απλές και ξεκάθαρες αρχιτεκτονικές. Η ουσία του KISS είναι να αποφεύγει υπερβολικά σχεδιασμένες λύσεις.

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

Το SOLID αποτελείται από πέντε αρχές σε μία: ενιαία ευθύνη, Open-closed, αντικατάσταση του Liskov, διαχωρισμό διεπαφών και αντιστροφή εξάρτησης. Για να είμαστε σύντομοι, η SOLID δηλώνει ότι ακολουθώντας αυτές τις αρχές διευκολύνεται η συντήρηση και δοκιμή των εφαρμογών.

Με λίγα λόγια, το TDD βοηθά στη δημιουργία ενός κομψού και απλού κώδικα που είναι εύκολο να διατηρηθεί.

Όπως είπε εύστοχα ο Robert Martin.

"Ο καθαρός κώδικας μοιάζει πάντα με τον τρόπο που γράφτηκε από κάποιον που τον νοιάζει".

βιβλιογραφικές αναφορές

Extreme Προγραμματισμός: Kent Beck.

Ανάπτυξη ευέλικτου λογισμικού: Robert Martin

Επαναλήψεις: Martin Fowler

Σχετικά με τον Συγγραφέα-:

Ο Ravi Rajan είναι ένας παγκόσμιος διαχειριστής προγραμμάτων πληροφορικής με έδρα το Μουμπάι της Ινδίας. Είναι επίσης ένας άπληστος blogger, συγγραφέας ποίησης Haiku, ενθουσιώδης αρχαιολόγος και μανιακός ιστορίας. Συνδεθείτε με τον Ravi σε LinkedIn, Medium και Twitter.

Αυτή η ιστορία δημοσιεύεται στο The Startup, το μεγαλύτερο δημοσίευμα επιχειρηματικής δραστηριότητας του Medium ακολουθούμενο από +438.678 άτομα.

Εγγραφείτε για να λάβετε τις κορυφαίες ιστορίες μας εδώ.