Τι είναι η Δοκιμαστική Ανάπτυξη (TDD); Παράδειγμα

Τι είναι η Δοκιμαστική Ανάπτυξη (TDD);

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

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

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

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

Πώς να εκτελέσετε τη δοκιμή TDD

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

1. Προσθέστε ένα τεστ.
2. Εκτελέστε όλες τις δοκιμές και δείτε εάν οποιαδήποτε νέα δοκιμή αποτυγχάνει.
3. Γράψε λίγο κώδικα.
4. Εκτελέστε δοκιμές και κωδικό Refactor.
5. Επαναλαμβάνω.

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

1. Γράψε ένα τεστ
2. Κάντε το να τρέξει.
3. Αλλάξτε τον κωδικό για να το κάνετε σωστό π.χ. Refactor.
4. Επαναλάβετε τη διαδικασία.

Μερικές διευκρινίσεις για το TDD:

• Η προσέγγιση TDD δεν αφορά ούτε τη «Δοκιμή» ούτε τη «Σχεδίαση».
• TDD δεν σημαίνει «γράψτε μερικές από τις δοκιμές και στη συνέχεια δημιουργήστε ένα σύστημα που περνάει τις δοκιμές.
• Το TDD δεν σημαίνει «κάντε πολλές δοκιμές».

TDD Vs. Παραδοσιακές Δοκιμές

Παρακάτω είναι η κύρια διαφορά μεταξύ της ανάπτυξης βάσει δοκιμής και της παραδοσιακής δοκιμής:

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

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

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

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

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

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

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

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

Ο κύκλος ζωής της AMDD

Στο Model-driven Development (MDD), δημιουργούνται εκτεταμένα μοντέλα πριν γραφτεί ο πηγαίος κώδικας. Ποια με τη σειρά τους έχουν μια ευέλικτη προσέγγιση;

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

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

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

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

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

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

Μοντελοποίηση επανάληψης

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

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

Καταιγισμός μοντέλου

Αυτό είναι επίσης γνωστό ως Just in time Modeling.

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

Δοκιμαστική Ανάπτυξη (TDD)

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

Revβλ

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

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

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

TDD Frameworks

Ακολουθεί η λίστα των καλύτερων πλαισίων ανάπτυξης βάσει δοκιμής (TDD).

1. Junit
2. TestNG
3. csUnit και NUnit
4. Rspec

Τώρα, ας μάθουμε τη Δοκιμαστική Ανάπτυξη με παράδειγμα.

Παράδειγμα TDD

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

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

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

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

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

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

Η έξοδος ΠΕΡΑΣΤΕΙ όπως φαίνεται παρακάτω.

Παραγωγή:

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

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

Έτσι, κάνουμε Refactor (αλλάξουμε τον κωδικό) ως εξής:

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

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

Παραγωγή:

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

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

Ακολουθούν τα κύρια πλεονεκτήματα της Δοκιμαστικής Ανάπτυξης στη Μηχανική Λογισμικού:

Πρόωρη ειδοποίηση σφάλματος.

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

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

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

Εμπιστοσύνη στο Refactor

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

Καλό για ομαδική εργασία

• Ελλείψει οποιουδήποτε μέλους της ομάδας, τα άλλα μέλη της ομάδας μπορούν εύκολα να παραλάβουν και να εργαστούν πάνω στον κώδικα. Βοηθά επίσης την ανταλλαγή γνώσεων, καθιστώντας έτσι την ομάδα πιο αποτελεσματική συνολικά.

Καλό για προγραμματιστές

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

Σύνοψη

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