Τι είναι το Test Driven Development (TDD); Εκμάθηση με Παράδειγμα

Δοκιμαστική ανάπτυξη

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

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

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

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

Σε αυτό το σεμινάριο, θα μάθετε περισσότερα για-

Πώς να εκτελέσετε το τεστ TDD
TDD εναντίον Παραδοσιακές δοκιμές
Τι είναι το TDD αποδοχής και το TDD προγραμματιστή
Κλιμάκωση TDD μέσω Agile Model Driven Development (AMDD)
Δοκιμή βάσει ανάπτυξης (TDD) Vs. Agile Model Driven Development (AMDD)
Παράδειγμα TDD
Οφέλη του TDD

Πώς να εκτελέσετε το τεστ TDD

Τα ακόλουθα βήματα καθορίζουν τον τρόπο εκτέλεσης της δοκιμής TDD,

Προσθέστε μια δοκιμή.
Εκτελέστε όλες τις δοκιμές και δείτε εάν αποτύχει οποιαδήποτε νέα δοκιμή.
Γράψτε κάποιο κωδικό.
Εκτελέστε δοκιμές και κωδικό Refactor.
Επαναλαμβάνω.

Ο κύκλος TDD ορίζει

Γράψτε μια δοκιμή
Κάντε το να τρέξει.
Αλλάξτε τον κωδικό για να τον κάνετε σωστό, δηλαδή Refactor.
Επαναλάβετε τη διαδικασία.

Μερικές διευκρινίσεις σχετικά με το TDD:

Το TDD δεν αφορά ούτε το "Testing" ούτε το "Design".
Το TDD δεν σημαίνει "γράψτε μερικές από τις δοκιμές και, στη συνέχεια, δημιουργήστε ένα σύστημα που περνά τις δοκιμές.
Το TDD δεν σημαίνει "κάνετε πολλές δοκιμές".

TDD εναντίον Παραδοσιακές δοκιμές

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

Με τις παραδοσιακές δοκιμές, μια επιτυχημένη δοκιμή εντοπίζει ένα ή περισσότερα ελαττώματα. Είναι ίδιο με το TDD. Όταν μια δοκιμή αποτύχει, έχετε σημειώσει πρόοδο, επειδή γνωρίζετε ότι πρέπει να επιλύσετε το πρόβλημα.
Το TDD διασφαλίζει ότι το σύστημά σας πληροί πραγματικά τις απαιτήσεις που ορίζονται για αυτό. Βοηθά στην οικοδόμηση της εμπιστοσύνης σας για το σύστημά σας.
Στο TDD δίνεται μεγαλύτερη έμφαση στον κώδικα παραγωγής που επαληθεύει εάν η δοκιμή θα λειτουργήσει σωστά. Στις παραδοσιακές δοκιμές, μεγαλύτερη έμφαση δίνεται στο σχεδιασμό δοκιμαστικών περιπτώσεων. Εάν το τεστ θα δείξει την ορθή / ακατάλληλη εκτέλεση της εφαρμογής προκειμένου να ικανοποιηθούν οι απαιτήσεις.
Στο TDD, επιτυγχάνετε δοκιμή κάλυψης 100%. Κάθε γραμμή κώδικα δοκιμάζεται, σε αντίθεση με τις παραδοσιακές δοκιμές.
Ο συνδυασμός τόσο των παραδοσιακών δοκιμών όσο και του TDD οδηγεί στη σημασία της δοκιμής του συστήματος παρά στην τελειότητα του συστήματος.
Στο Agile Modeling (AM), θα πρέπει να "δοκιμάσετε με σκοπό". Πρέπει να ξέρετε γιατί δοκιμάζετε κάτι και σε ποιο επίπεδο πρέπει να δοκιμάσετε.

Τι είναι το TDD αποδοχής και το TDD προγραμματιστή

Υπάρχουν δύο επίπεδα TDD

Αποδοχή TDD (ATDD): Με το ATDD γράφετε ένα τεστ αποδοχής. Αυτή η δοκιμή πληροί την απαίτηση της προδιαγραφής ή ικανοποιεί τη συμπεριφορά του συστήματος. Μετά από αυτό γράψτε αρκετό κώδικα παραγωγής / λειτουργικότητας για να εκπληρώσετε αυτόν τον έλεγχο αποδοχής. Η δοκιμή αποδοχής επικεντρώνεται στη συνολική συμπεριφορά του συστήματος. Το ATDD ήταν επίσης γνωστό ως Behavioral Driven Development (BDD).
Προγραμματιστής TDD: Με τον προγραμματιστή TDD γράφετε μία δοκιμή προγραμματιστή, δηλαδή δοκιμή μονάδας και, στη συνέχεια, αρκετό κώδικα παραγωγής για να εκπληρώσετε αυτήν τη δοκιμή. Το τεστ μονάδας επικεντρώνεται σε κάθε μικρή λειτουργικότητα του συστήματος. Ο προγραμματιστής TDD ονομάζεται απλά TDD.
Ο κύριος στόχος του ATDD και του TDD είναι να καθορίσετε λεπτομερείς, εκτελέσιμες απαιτήσεις για τη λύση σας σε μια χρονική στιγμή (JIT). JIT σημαίνει να λαμβάνονται υπόψη μόνο οι απαιτήσεις που απαιτούνται στο σύστημα Αυξήστε λοιπόν την αποτελεσματικότητα.

Κλιμάκωση TDD μέσω Agile Model Driven Development (AMDD)

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

Έτσι, η AMDD χρησιμοποίησε για μεγαλύτερα ζητήματα.

Ο κύκλος ζωής του AMDD.

Στην Ανάπτυξη βάσει μοντέλου (MDD), δημιουργούνται εκτεταμένα μοντέλα πριν από τη σύνταξη του πηγαίου κώδικα. Ποιος με τη σειρά του έχει μια ευέλικτη προσέγγιση;

Στην παραπάνω εικόνα, κάθε πλαίσιο αντιπροσωπεύει μια αναπτυξιακή δραστηριότητα.

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

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

Επανάληψη 0: Οραματισμός

Υπάρχουν δύο κύριες δευτερεύουσες ενεργοποιήσεις.

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

Μοντελοποίηση επανάληψης:
Εδώ η ομάδα πρέπει να σχεδιάσει το έργο που θα γίνει για κάθε επανάληψη.

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

Μοντέλο καταιγισμού:
Αυτό είναι επίσης γνωστό ως μοντελοποίηση Just in time.

Εδώ η συνεδρία μοντελοποίησης περιλαμβάνει μια ομάδα 2/3 μελών που συζητούν θέματα σε χαρτί ή πίνακα.
Ένα μέλος της ομάδας θα ζητήσει από ένα άλλο να κάνει μοντέλο μαζί τους. Αυτή η συνεδρία μοντελοποίησης θα διαρκέσει περίπου 5 έως 10 λεπτά. Όπου τα μέλη της ομάδας συγκεντρώνονται για να μοιραστούν τον πίνακα / χαρτί.
Εξετάζουν ζητήματα έως ότου δεν βρουν την κύρια αιτία του προβλήματος. Ακριβώς εγκαίρως, εάν ένα μέλος της ομάδας εντοπίσει το ζήτημα που θέλει να επιλύσει, τότε θα πάρει γρήγορη βοήθεια από άλλα μέλη της ομάδας.
Στη συνέχεια, άλλα μέλη της ομάδας εξερευνούν το ζήτημα και στη συνέχεια όλοι συνεχίζουν όπως πριν. Ονομάζεται επίσης ως stand-up μοντελοποίηση ή πελάτης QA συνεδρίες.

Δοκιμή βάσει ανάπτυξης (TDD).

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

Κριτικές

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

Δοκιμή βάσει ανάπτυξης (TDD) Vs. Agile Model Driven Development (AMDD)

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

Παράδειγμα TDD

Εδώ σε αυτό το παράδειγμα, θα καθορίσουμε έναν κωδικό πρόσβασης τάξης. Για αυτήν την τάξη, θα προσπαθήσουμε να ικανοποιήσουμε τις ακόλουθες προϋποθέσεις.

Προϋπόθεση αποδοχής κωδικού πρόσβασης:

Ο κωδικός πρόσβασης πρέπει να είναι μεταξύ 5 και 10 χαρακτήρων.

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

Σενάριο 1 : Για να εκτελέσετε τη δοκιμή, δημιουργούμε τάξη PasswordValidator ();

Θα τρέξουμε πάνω από την κλάση TestPassword ();

Η έξοδος έχει περάσει όπως φαίνεται παρακάτω.

Έξοδος :

Σενάριο 2 : Εδώ μπορούμε να δούμε στη μέθοδο TestPasswordLength () δεν υπάρχει ανάγκη δημιουργίας μιας παρουσίας της κλάσης PasswordValidator. Instance σημαίνει δημιουργία αντικειμένου κλάσης για αναφορά των μελών (μεταβλητές / μέθοδοι) αυτής της κλάσης.

Θα αφαιρέσουμε την κλάση PasswordValidator pv = new PasswordValidator () από τον κώδικα. Μπορούμε να καλέσουμε τη μέθοδο isValid () απευθείας από το PasswordValidator. IsValid ("Abc123") . (Δείτε την παρακάτω εικόνα)

Έτσι, το Refactor (αλλαγή κώδικα) όπως παρακάτω:

Σενάριο 3 : Μετά την επανακατασκευή, η έξοδος δείχνει την κατάσταση αποτυχίας (δείτε την εικόνα παρακάτω) αυτό οφείλεται στο ότι έχουμε καταργήσει την παρουσία. Επομένως, δεν υπάρχει αναφορά στη μη στατική μέθοδο isValid ().

Επομένως, πρέπει να αλλάξουμε αυτήν τη μέθοδο προσθέτοντας "στατική" λέξη πριν από το Boolean ως δημόσιο στατικό boolean isValid (String password). Refactoring Class PasswordValidator () για να αφαιρέσετε το παραπάνω σφάλμα για να περάσετε τον έλεγχο.

Παραγωγή:

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

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

Πρώιμη ειδοποίηση σφάλματος.
Οι προγραμματιστές δοκιμάζουν τον κώδικά τους, αλλά στον κόσμο της βάσης δεδομένων, αυτό συχνά αποτελείται από χειροκίνητες δοκιμές ή εφάπαξ scripts. Χρησιμοποιώντας το TDD δημιουργείτε, με την πάροδο του χρόνου, μια σειρά από αυτοματοποιημένες δοκιμές που εσείς και οποιοσδήποτε άλλος προγραμματιστής μπορείτε να εκτελέσετε ξανά κατά βούληση.
Καλύτερος σχεδιασμός, καθαρότερος και πιο επεκτάσιμος κώδικας.
- Βοηθά να κατανοήσουμε πώς θα χρησιμοποιηθεί ο κώδικας και πώς αλληλεπιδρά με άλλες ενότητες.
- Καταλήγει σε καλύτερη απόφαση σχεδιασμού και πιο διατηρήσιμο κώδικα.
- Το TDD επιτρέπει τη σύνταξη μικρότερου κώδικα με ενιαία ευθύνη και όχι μονολιθικές διαδικασίες με πολλαπλές ευθύνες. Αυτό κάνει τον κώδικα απλούστερο κατανοητό.
- Το TDD αναγκάζει επίσης να γράψει μόνο κωδικό παραγωγής για να περάσει δοκιμές με βάση τις απαιτήσεις του χρήστη.
Εμπιστοσύνη στον αντιδραστήρα
- Εάν διορθώσετε τον κωδικό, μπορεί να υπάρχουν πιθανότητες διακοπών στον κώδικα. Έτσι, έχοντας ένα σύνολο αυτοματοποιημένων δοκιμών, μπορείτε να διορθώσετε αυτά τα διαλείμματα πριν από την κυκλοφορία. Η σωστή προειδοποίηση θα δοθεί εάν εντοπιστούν διαλείμματα όταν χρησιμοποιούνται αυτοματοποιημένες δοκιμές.
- Η χρήση του TDD, θα οδηγήσει σε ταχύτερο, πιο επεκτάσιμο κώδικα με λιγότερα σφάλματα που μπορούν να ενημερωθούν με ελάχιστους κινδύνους.
Καλό για ομαδική εργασία
Εάν δεν υπάρχει κανένα μέλος της ομάδας, άλλα μέλη της ομάδας μπορούν εύκολα να παραλάβουν και να εργαστούν στον κώδικα. Βοηθά επίσης την ανταλλαγή γνώσεων, κάνοντας έτσι την ομάδα πιο αποτελεσματική συνολικά.
Καλό για προγραμματιστές
Αν και οι προγραμματιστές πρέπει να αφιερώσουν περισσότερο χρόνο στη σύνταξη δοκιμαστικών περιπτώσεων TDD, χρειάζεται πολύ λιγότερος χρόνος για τον εντοπισμό σφαλμάτων και την ανάπτυξη νέων λειτουργιών. Θα γράψετε καθαρότερο, λιγότερο περίπλοκο κώδικα.

Περίληψη:

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

Αυτό το άρθρο συνεισφέρει ο Kanchan Kulkarni