Πότε γράφετε τον "πραγματικό" κώδικα στο TDD;

johnny 08/19/2017. 11 answers, 20.464 views
tdd

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

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

Edit: Χάρη σε όλους όσους απάντησαν. Όλες οι απαντήσεις σας με βοήθησαν πάρα πολύ. Φαίνεται ότι υπάρχουν διαφορετικές ιδέες σε ό, τι ζητούσα ή μπερδευόμουν και ίσως υπάρχει, αλλά αυτό που ζητούσα ήταν να πω ότι έχω μια αίτηση για την οικοδόμηση ενός σχολείου.

Στο σχεδιασμό μου, έχω μια αρχιτεκτονική με την οποία θέλω να ξεκινήσω, τις Ιστορίες χρηστών, κλπ. Και ούτω καθεξής. Από εδώ, παίρνω αυτές τις Ιστορίες Χρήστη και δημιουργώ μια δοκιμή για να δοκιμάσω την Ιστορία Χρήστη. Ο Χρήστης λέει: Έχουμε άτομα που εγγράφονται στο σχολείο και καταβάλλουν τέλη εγγραφής. Έτσι, σκέφτομαι έναν τρόπο να αποτύχει αυτό. Με αυτόν τον τρόπο σχεδιάζω μια δοκιμαστική κλάση για την κατηγορία X (ίσως σπουδαστής), η οποία θα αποτύχει. Στη συνέχεια, δημιουργώ την τάξη "Φοιτητής". Ίσως το "Σχολείο" δεν ξέρω.

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

Μοιάζω αυτό με το να σκέφτομαι την Επανάσταση. Η επανάληψη δεν είναι μια σκληρή ιδέα. Μπορεί να είναι πιο δύσκολο να το παρακολουθήσετε στην πραγματικότητα, αλλά στην πραγματικότητα, το πιο δύσκολο κομμάτι είναι να γνωρίζετε, όταν η αναδρομή «σπάει», πότε πρέπει να σταματήσετε (φυσικά, η γνώμη μου). Γι 'αυτό πρέπει να σκεφτώ τι σταματά την Επανάσταση πρώτα. Είναι μόνο μια ατελής αναλογία και υποθέτει ότι κάθε επαναληπτική επανάληψη είναι ένα "πέρασμα". Και πάλι, μόνο μια γνώμη.

Στην εφαρμογή, το σχολείο είναι πιο δύσκολο να δει. Τα αριθμητικά και τραπεζικά βιβλία είναι "εύκολες" με την έννοια που μπορείτε να χρησιμοποιήσετε απλή αριθμητική. Μπορώ να δω ένα + b και να επιστρέψω 0, κλπ. Στην περίπτωση ενός συστήματος ανθρώπων, πρέπει να σκεφτώ σκληρότερα για το πώς να το implement . Έχω την ιδέα του αποτυχίας, του περάσματος, του επαναστάτη (κυρίως λόγω της μελέτης και αυτής της ερώτησης.)

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

Ή, ίσως αυτό δείχνει ότι είμαι ακόμα μπερδεμένος.

5 Comments
187 hobbs 07/25/2017
Αφού οι ΤΔΔ πηγαίνουν στο σπίτι για τη νύχτα.
14 Goyo 07/25/2017
Γιατί νομίζετε ότι ο κώδικας που γράψατε δεν είναι πραγματικός;
2 johnny 07/26/2017
@RubberDuck Περισσότερο από τις υπόλοιπες απαντήσεις. Είμαι βέβαιος ότι θα το αναφερθώ σύντομα. Εξακολουθεί να είναι ξένη, αλλά δεν πρόκειται να το εγκαταλείψω. Αυτό που είπατε ήταν λογικό. Προσπαθώ απλώς να το κάνω λογικό στο πλαίσιο μου ή σε μια κανονική επιχειρηματική εφαρμογή. Ίσως ένα σύστημα απογραφής ή κάτι παρόμοιο. Πρέπει να το εξετάσω. Είμαι ευγνώμων για το χρόνο σας όμως. Ευχαριστώ.
1 Edmund Reed 07/26/2017
Οι απαντήσεις έχουν ήδη χτυπήσει το καρφί στο κεφάλι, αλλά όσο όλες οι δοκιμές σας περνούν και δεν χρειάζεστε νέες δοκιμές / λειτουργίες, μπορεί να υποτεθεί ότι ο κωδικός που έχετε τελειώσει, χρωματίζεται με ράβδους.
3 Borjab 07/26/2017
Υπάρχει μια υπόθεση που μπορεί να είναι προβληματική στο θέμα "Έχω ένα αρκετά σύνθετο αντικείμενο με μια πολύπλοκη μέθοδο". Στο TDD γράφετε πρώτα τις δοκιμές σας, έτσι ώστε να ξεκινάτε με έναν απλό κώδικα. Αυτό θα σας αναγκάσει να κωδικοποιήσετε μια φιλική προς τις δοκιμές δομή που θα πρέπει να είναι αρθρωτή. Μια πολύπλοκη συμπεριφορά θα δημιουργηθεί συνδυάζοντας απλούστερα αντικείμενα. Αν τελειώσετε με ένα αρκετά περίπλοκο αντικείμενο ή μέθοδο, τότε είναι όταν επαναπροσδιορίζεστε

11 Answers


RubberDuck 07/27/2017.

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

Δεν "πηγαίνετε πίσω" και γράφετε "πραγματικό κώδικα". Είναι όλοι πραγματικός κώδικας. Αυτό που κάνετε είναι να επιστρέψετε και να προσθέσετε μια άλλη δοκιμασία που σας forces να change τον κωδικό σας για να κάνετε το νέο τεστ.

Όσο για τον κώδικα που γράφετε πριν επαναλάβετε; Κανένας. Μπορείτε να γράψετε zero κώδικα χωρίς μια αποτυχημένη δοκιμασία που σας forces να γράψετε περισσότερο κώδικα.

Παρατηρήστε το μοτίβο;

Ας περπατήσουμε (άλλο) απλό παράδειγμα, ελπίζοντας ότι βοηθάει.

 Assert.Equal("1", FizzBuzz(1)); 

Εύκολη πεζή.

 public String FizzBuzz(int n) {
    return 1.ToString();
} 

Όχι αυτό που θα ονομάζατε πραγματικό κώδικα, σωστά; Ας προσθέσουμε μια δοκιμή που αναγκάζει μια αλλαγή.

 Assert.Equal("2", FizzBuzz(2)); 

Θα μπορούσαμε να κάνουμε κάτι ανόητο όπως if n == 1 , αλλά θα παραλείψουμε την λογική λύση.

 public String FizzBuzz(int n) {
    return n.ToString();
} 

Δροσερός. Αυτό θα λειτουργήσει για όλους τους αριθμούς μη FizzBuzz. Ποια είναι η επόμενη είσοδος που θα αναγκάσει τον κώδικα παραγωγής να αλλάξει;

 Assert.Equal("Fizz", FizzBuzz(3));

public String FizzBuzz(int n) {
    if (n == 3)
        return "Fizz";
    return n.ToString();
} 

Και ξανα. Γράψτε μια δοκιμή που δεν θα περάσει ακόμα.

 Assert.Equal("Fizz", FizzBuzz(6));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    return n.ToString();
} 

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

Δεν έχουμε γράψει ακόμη μια δοκιμασία για το "Buzz", οπότε ας γράψουμε αυτό.

 Assert.Equal("Buzz", FizzBuzz(5));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n == 5)
        return "Buzz"
    return n.ToString();
} 

Και πάλι, ξέρουμε ότι υπάρχει άλλη περίπτωση που πρέπει να χειριστούμε.

 Assert.Equal("Buzz", FizzBuzz(10));

public String FizzBuzz(int n) {
    if (n % 3 == 0)
        return "Fizz";
    if (n % 5 == 0)
        return "Buzz"
    return n.ToString();
} 

Και τώρα μπορούμε να χειριστούμε όλα τα πολλαπλάσια των 5 που δεν είναι επίσης πολλαπλάσια των 3.

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

 private bool isDivisibleBy(int divisor, int input) {
    return (input % divisor == 0);
}

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

Δροσερός. Τώρα έχουμε αφαιρέσει την επικάλυψη και δημιούργησε μια καλά ονομάζεται λειτουργία. Ποιο είναι το επόμενο τεστ που μπορούμε να γράψουμε που θα μας αναγκάσει να αλλάξουμε τον κώδικα; Λοιπόν, αποφεύγουμε την περίπτωση όπου ο αριθμός διαιρείται και από τις 3 και 5. Ας γράψουμε τώρα.

 Assert.Equal("FizzBuzz", FizzBuzz(15));

public String FizzBuzz(int n) {
    if (isDivisibleBy(3, n) && isDivisibleBy(5, n))
        return "FizzBuzz";
    if (isDivisibleBy(3, n))
        return "Fizz";
    if (isDivisibleBy(5, n))
        return "Buzz"
    return n.ToString();
} 

Οι δοκιμές περνούν, αλλά έχουμε περισσότερη επανάληψη. Έχουμε επιλογές, αλλά πρόκειται να εφαρμόσω "Extract Local Variable" μερικές φορές, έτσι ώστε να είμαστε refactoring αντί να ξαναγράψουμε.

 public String FizzBuzz(int n) {

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

Και καλύψαμε κάθε λογική συνεισφορά, αλλά τι γίνεται με την unreasonable εισροή; Τι συμβαίνει εάν περάσουμε 0 ή αρνητικό; Γράψτε τις περιπτώσεις δοκιμής.

 public String FizzBuzz(int n) {

    if (n < 1)
        throw new InvalidArgException("n must be >= 1);

    var isDivisibleBy3 = isDivisibleBy(3, n);
    var isDivisibleBy5 = isDivisibleBy(5, n);

    if ( isDivisibleBy3 && isDivisibleBy5 )
        return "FizzBuzz";
    if ( isDivisibleBy3 )
        return "Fizz";
    if ( isDivisibleBy5 )
        return "Buzz"
    return n.ToString();
} 

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

Έτσι, ήμουν σε θέση να το κάνω απλά ψάχνοντας για μια δοκιμή που ήξερα ότι δεν θα περάσει σε κάθε βήμα, αλλά είχα πολλή πρακτική. Όταν δουλεύω, τα πράγματα δεν είναι ποτέ τόσο απλά και ίσως να μην γνωρίζω πάντα τι δοκιμασία θα αναγκάσει μια αλλαγή. Μερικές φορές θα γράψω ένα τεστ και θα εκπλαγώ να το βλέπω να περνάει ήδη! Συστήνω ιδιαίτερα να έχετε τη συνήθεια να δημιουργείτε μια "λίστα δοκιμών" πριν ξεκινήσετε. Αυτός ο κατάλογος δοκιμών θα πρέπει να περιέχει όλες τις "ενδιαφέρουσες" εισόδους που μπορείτε να σκεφτείτε. Ίσως να μην τα χρησιμοποιήσετε όλα και πιθανότατα να προσθέσετε περιπτώσεις καθώς πηγαίνετε, αλλά αυτή η λίστα χρησιμεύει ως οδικός χάρτης. Η δοκιμαστική λίστα μου για το FizzBuzz θα έμοιαζε κάπως έτσι.

  • Αρνητικός
  • Μηδέν
  • Ενας
  • Δύο
  • Τρία
  • Τέσσερα
  • Πέντε
  • Έξι (μη τετριμμένο πολλαπλάσιο του 3)
  • Εννέα (3 τετράγωνα)
  • Δέκα (μη τετριμμένο πολλαπλάσιο του 5)
  • 15 (πολλαπλάσια των 3 & 5)
  • 30 (μη τετριμμένο πολλαπλάσιο των 3 & 5)
5 comments
3 maple_shaft♦ 07/27/2017
Τα σχόλια δεν προορίζονται για εκτεταμένη συζήτηση. αυτή η συζήτηση έχει μεταφερθεί στη συζήτηση .
40 GManNickG 07/27/2017
Αν δεν είμαι εντελώς παρεξηγημένη αυτή η απάντηση: "Θα μπορούσαμε να κάνουμε κάτι ανόητο όπως αν n == 1, αλλά θα παραλείψουμε την λογική λύση." - το όλο πράγμα ήταν ανόητο. Αν γνωρίζετε μπροστά θέλετε μια λειτουργία που κάνει <spec>, γράψτε δοκιμές για <spec> και παραλείψτε το μέρος όπου γράφετε εκδόσεις που προφανώς αποτυγχάνουν <spec>. Αν βρείτε σφάλμα στο <spec>, τότε βεβαιωθείτε ότι: γράψτε πρώτα μια δοκιμή για να επαληθεύσετε ότι μπορείτε να την ασκήσετε πριν την επιδιόρθωση και να παρακολουθήσετε τις δοκιμαστικές διελεύσεις μετά την επιδιόρθωση. Αλλά δεν υπάρχει καμία ανάγκη να πλαστογραφήσετε όλα αυτά τα ενδιάμεσα βήματα.
15 user3791372 07/28/2017
Τα σχόλια που επισημαίνουν τις σημαντικές αδυναμίες αυτής της απάντησης και το TDD γενικά έχουν μεταφερθεί στη συζήτηση. Εάν σκέφτεστε να χρησιμοποιήσετε το TDD, διαβάστε το "chat". Δυστυχώς, τα σχόλια "ποιότητας" είναι πλέον κρυμμένα ανάμεσα σε ένα φορτίο συζήτησης για μελλοντικούς μαθητές να διαβάσουν.
nbro 07/28/2017
Θα ήμουν πιο ακριβής όσον αφορά το περιεχόμενο αυτού του "δοκιμαστικού καταλόγου", αν θέλετε να βελτιώσετε αυτήν την απάντηση. Θα ήθελα να μιλήσω ρητά για τις "οριακές αξίες" και την "διαίρεση κατηγορίας".
2 hvd 07/30/2017
@GManNickG Πιστεύω ότι το θέμα είναι να πάρει το σωστό ποσό των δοκιμών. Η σύνταξη των δοκιμών εκ των προτέρων καθιστά εύκολο να χάσετε τις ειδικές περιπτώσεις που πρέπει να δοκιμάζονται, οδηγώντας είτε σε καταστάσεις που δεν καλύπτονται επαρκώς στις δοκιμές, είτε στην ουσιαστικά την ίδια κατάσταση που καλύπτεται άσκοπα από πολλές φορές στις δοκιμές. Εάν μπορείτε να το κάνετε χωρίς αυτά τα ενδιάμεσα βήματα, θαυμάσια! Ο καθένας όμως δεν μπορεί να το κάνει ακόμα, όμως, είναι κάτι που απαιτεί πρακτική.

GenericJon 07/24/2017.

Ο "πραγματικός" κώδικας είναι ο κώδικας που γράφετε για να κάνετε τη δική σας δοκιμή. Really . Είναι τόσο απλό.

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

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

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

5 comments
44 Derek Elkins 07/24/2017
Οι δοκιμές μονάδας δεν μπορούν στην πραγματικότητα να καλύψουν τις απαιτήσεις του προϊόντος σας για ακόμη και σχετικά ασήμαντες απαιτήσεις. Στην καλύτερη περίπτωση, δοκιμάζουν το χώρο εισόδου-εξόδου και η ιδέα είναι ότι εσείς (σωστά) γενικεύετε στον πλήρη χώρο εισόδου-εξόδου. Φυσικά, ο κωδικός σας θα μπορούσε απλώς να είναι ένας μεγάλος switch με μια υπόθεση για κάθε δοκιμή μονάδας που θα περάσει όλες τις δοκιμές και θα αποτύχει για οποιεσδήποτε άλλες εισόδους.
8 Taemyr 07/25/2017
Το @DerekElkins TDD δίνει εντολή για αποτυχημένες δοκιμές. Δεν αποτυγχάνουν δοκιμές μονάδας.
6 jonrsharpe 07/25/2017
@DerekElkins γι 'αυτό δεν γράφετε απλώς μονάδες δοκιμών, αλλά και γιατί υπάρχει μια γενική υπόθεση ότι προσπαθείτε να κάνετε κάτι όχι μόνο ψεύτικο!
35 Derek Elkins 07/25/2017
@jonrsharpe Με αυτή τη λογική, δεν θα έγραφα ποτέ τετριμμένες εφαρμογές. Παραδείγματος χάριν, στο παράδειγμα FizzBuzz στην απάντηση του RubberDuck (το οποίο χρησιμοποιεί μόνο δοκιμές μονάδων), η πρώτη εφαρμογή σαφώς «απλά το παραπλανά». Η κατανόησή μου για την ερώτηση είναι ακριβώς αυτή η διχοτόμηση ανάμεσα στον κώδικα γραφής που γνωρίζετε ότι είναι ελλιπής και κώδικας που πραγματικά πιστεύετε ότι θα εφαρμόσει την απαίτηση, τον "πραγματικό κώδικα". Ο "μεγάλος switch " μου προοριζόταν ως λογικό άκρο να γράφει το ελάχιστο για να κάνουν τις δοκιμές πράσινες. Θεωρώ την ερώτηση του OP ως εξής: Πού είναι στην TDD η αρχή ότι αποφεύγεται αυτή η μεγάλη switch ;
2 Luaan 07/25/2017
@GenericJon Αυτό είναι λίγο πολύ αισιόδοξο στην εμπειρία μου :) Για ένα, υπάρχουν άνθρωποι που απολαμβάνουν ανόητη επαναλαμβανόμενη εργασία. Θα είναι πιο ευτυχισμένοι με μια τεράστια δήλωση διακόπτη παρά με μια "περίπλοκη λήψη αποφάσεων". Και για να χάσουν τη δουλειά τους, είτε θα χρειαζόταν κάποιον που να τους καλεί για την τεχνική (και έχουν καλύτερα αποδεικτικά στοιχεία ότι στην πραγματικότητα χάνουν τις ευκαιρίες / χρήματα της εταιρείας!), Ή κάνουν εξαιρετικά άσχημα. Μετά την ανάληψη της συντήρησης σε πολλά τέτοια έργα, μπορώ να πω ότι είναι εύκολο για πολύ αφελείς κώδικα να διαρκέσει για δεκαετίες, εφόσον καθιστά τον πελάτη ευτυχισμένο (και πληρώνει).

Carl Raymond 07/24/2017.

Η σύντομη απάντηση είναι ότι ο "πραγματικός κώδικας" είναι ο κώδικας που κάνει τη δοκιμαστική διέλευση. Εάν μπορείτε να κάνετε τη δοκιμαστική διέλευσή σας με κάτι άλλο από τον πραγματικό κώδικα, προσθέστε περισσότερες δοκιμές!

Συμφωνώ ότι πολλά tutorials σχετικά με το TDD είναι απλοϊκά. Αυτό λειτουργεί εναντίον τους. Μια πολύ απλή δοκιμή για μια μέθοδο που, για παράδειγμα, υπολογίζει 3 + 8 πραγματικά δεν έχει άλλη επιλογή παρά να υπολογίσει επίσης 3 + 8 και να συγκρίνει το αποτέλεσμα. Αυτό το κάνει να μοιάζει σαν να απλά να αντιγράφετε τον κώδικα σε όλο τον κόσμο, και ότι ο έλεγχος είναι άσκοπος, επιρρεπής σε σφάλματα επιπλέον εργασία.

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

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

4 comments
6 Steve Jessop 07/26/2017
Προσωπικά, η δοκιμή που θα γράψω θα είναι assertEqual(plus(3,8), 11) , δεν assertEqual(plus(3,8), my_test_implementation_of_addition(3,8)) . Για πιο σύνθετες περιπτώσεις, αναζητάτε πάντα ένα μέσο για να αποδείξετε το αποτέλεσμα σωστά, other than δυναμικό υπολογισμό του σωστού αποτελέσματος στη δοκιμή και τον έλεγχο της ισότητας.
Steve Jessop 07/26/2017
Έτσι για έναν πραγματικά ανόητο τρόπο να το κάνετε για αυτό το παράδειγμα, μπορείτε να αποδείξετε ότι το plus(3,8) επέστρεψε το σωστό αποτέλεσμα αφαιρώντας 3 από αυτό, αφαιρώντας 8 από αυτό, και ελέγχοντας το αποτέλεσμα εναντίον 0. Αυτό είναι τόσο προφανές assertEqual(plus(3,8), 3+8) για να είναι λίγο παράλογο, αλλά αν ο υπό δοκιμή κώδικας δημιουργεί κάτι πιο περίπλοκο από έναν ακέραιο αριθμό, τότε παίρνει το αποτέλεσμα και ελέγχει κάθε μέρος για την ορθότητα είναι συχνά τη σωστή προσέγγιση. Εναλλακτικά, κάτι σαν το for (i=0, j=10; i < 10; ++i, ++j) assertEqual(plus(i, 10), j)
Steve Jessop 07/26/2017
... καθώς αποφεύγεται ο μεγάλος φόβος, που είναι ότι όταν γράφουμε το τεστ θα κάνουμε το ίδιο λάθος στο θέμα "πώς να προσθέσουμε 10" που κάναμε στον ζωντανό κώδικα. Έτσι, η δοκιμή αποφεύγει προσεκτικά να γράψει οποιοδήποτε κώδικα που προσθέτει 10 σε οτιδήποτε, στη δοκιμή ότι το plus() μπορεί να προσθέσει 10 στα πράγματα. Εξακολουθούμε να βασιζόμαστε στις τιμές των αρχικών βρόχων επαληθευμένων από τον προγραμματιστή, φυσικά.
3 Warbo 07/28/2017
Απλά θέλω να επισημάνω ότι ακόμη και αν γράφετε δοκιμές μετά το γεγονός, είναι ακόμα καλή ιδέα να τα παρακολουθήσετε αποτυγχάνουν. βρείτε κάποιο μέρος του κώδικα που φαίνεται κρίσιμο για ό, τι και αν εργάζεστε, τσιμπήστε το λίγο (π.χ. αντικαταστήστε ένα + με ένα - ή οτιδήποτε άλλο), εκτελέστε τις δοκιμές και παρακολουθήστε τους αποτυγχάνουν, ακυρώστε την αλλαγή και παρακολουθήστε τους. Πολλές φορές έχω κάνει αυτό το τεστ δεν αποτυγχάνει στην πραγματικότητα, καθιστώντας το χειρότερο από ό, τι άχρηστο: όχι μόνο δεν είναι ο έλεγχος τίποτα, αυτό μου δίνει ψευδή εμπιστοσύνη ότι κάτι είναι υπό δοκιμή!

Victor Cejudo 07/25/2017.

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

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

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

Ο Bob Martin το εξηγεί τέλεια εδώ .


CandiedOrange 07/25/2017.

Το μέρος του ανακλαστήρα καθαρίζεται όταν είστε κουρασμένοι και θέλετε να πάτε στο σπίτι.

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

Αυτό μπορεί να είναι τόσο απλό όσο η μετονομασία του GreetImpl στο GreetWorld προτού δημιουργήσετε μια κλάση GreetMom (μετά την προσθήκη μιας δοκιμής) για να προσθέσετε ένα χαρακτηριστικό που θα εκτυπώσει "Hi Mom".


graeme 07/27/2017.

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

Οι δοκιμές πρέπει να εκτελούνται κάθε φορά που κάνετε μια αλλαγή.

Το σύνθημα του κύκλου ζωής του TDD θα είναι: ΚΟΚΚΙΝΟΣ ΠΡΑΣΙΝΟΣ ΡΕΥΜΑΤΟΣ

RED : Γράψτε τις δοκιμές

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

REFACTOR : Καθαρίστε τον κώδικα, ονομάστε σωστά τις μεταβλητές. ΞΗΡΑΣΤΕ τον κώδικα.

5 comments
5 mcottle 07/25/2017
Ξέρω τι λέτε για τη φάση "Πράσινη" αλλά υπονοεί ότι οι τιμές επιστροφής σκληρών καλωδίων για να περάσουν οι δοκιμές θα ήταν ενδεδειγμένες. Σύμφωνα με την εμπειρία μου, η "Πράσινη" θα πρέπει να είναι μια έντιμη προσπάθεια να καταστεί ο κώδικας εργασίας ικανοποιημένος με την απαίτηση, μπορεί να μην είναι τέλειος αλλά θα πρέπει να είναι τόσο πλήρης και "αποθήκη" όπως ο κύριος του έργου μπορεί να διαχειριστεί σε ένα πρώτο πέρασμα. Ο επαναληπτικός έλεγχος είναι πιθανότατα καλύτερα να γίνει κάποια στιγμή αργότερα, αφού έχετε κάνει περισσότερη ανάπτυξη και τα προβλήματα με το πρώτο πέρασμα γίνονται πιο προφανή και ευκαιρίες για την εμφάνιση DRY.
graeme 07/25/2017
@mcottle θεωρώ όλα αυτά μέρος του ίδιου έργου. το τελειώσετε, στη συνέχεια καθαρίστε το. Περαιτέρω refactorings θα πρέπει να λαμβάνουν χώρα με το πέρασμα του χρόνου ως μέρος άλλων καθηκόντων.
1 Bryan Boettcher 07/25/2017
@mcottle: ίσως εκπλαγείτε πόσες υλοποιήσεις ενός repository μόνο για get-get μπορεί να είναι hardcoded τιμές στο codebase. :)
6 Kaz 07/25/2017
Γιατί θα γράψω κώδικα χάλια και θα το καθαρίζω, όταν μπορώ να ξεκλειδώσω ωραίο κώδικα ποιότητας παραγωγής σχεδόν τόσο γρήγορα όσο μπορώ να πληκτρολογήσω; :)
1 Kaz 07/27/2017
@TimothyTruckle Τι παίρνει 50 λεπτά για να βρει την απλούστερη δυνατή αλλαγή, αλλά μόνο 5 για να βρει τη δεύτερη απλούστερη δυνατή αλλαγή; Πηγαίνουμε με το δεύτερο απλούστερο ή συνεχίζουμε να ψάχνουμε για απλά;

Timothy Truckle 07/27/2017.

Πότε γράφετε τον "πραγματικό" κώδικα στο TDD;

Η red φάση είναι όπου write κώδικα.

Στη φάση refactoring ο πρωταρχικός στόχος είναι να delete κώδικα.

Στην red φάση κάνετε τίποτα για να κάνετε το τεστ as quick as possible και at any cost . Εξαιρείτε εντελώς τι έχετε ακούσει ποτέ για τις καλές πρακτικές κωδικοποίησης ή το σχεδιαστικό μοτίβο. Κάνοντας το τεστ πράσινο είναι όλα αυτά που έχουν σημασία.

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

Τέλος, βελτιώνετε την αναγνωσιμότητα με τη μετονομασία αναγνωριστικών και εξαγωγή magic numbers ή / και κυριολεκτικών συμβολοσειρών σε σταθερές.


Δεν είναι κόκκινο-refactor, είναι κόκκινο-πράσινο-refactor. - Ο Rob Kinyon

Ευχαριστώ που το δείξατε.

Έτσι είναι η green φάση όπου γράφετε τον real code

Στην red φάση γράφετε την executable specification ...

2 comments
Rob Kinyon 07/27/2017
Δεν είναι κόκκινο-refactor, είναι κόκκινο-πράσινο-refactor. Το "κόκκινο" παίρνετε τη δοκιμαστική σας σουίτα από πράσινο (όλες οι δοκιμές περνούν) στο κόκκινο (μία δοκιμή αποτυγχάνει). Το "πράσινο" είναι εκεί που παίρνετε χυδαία σου δοκιμαστική σουίτα από κόκκινο (μία δοκιμή αποτυγχάνει) σε πράσινο (όλες οι δοκιμές περνούν). Το "refactor" είναι εκεί που παίρνετε τον κωδικό σας και το κάνετε όμορφο κρατώντας όλες τις δοκιμές να περάσουν.
Timothy Truckle 07/27/2017
@RobKinyon Ευχαριστούμε, ενημερώσαμε την απάντηση.

Robert Andrzejuk 07/27/2017.

Γράφετε Real Code όλη την ώρα.

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

Νομίζετε ότι δεν γράφετε χρήσιμο ( real ) κώδικα, διότι σε μια στιγμή μπορείτε να το επαναπροσδιορίσετε.

Code-Refactoring είναι η διαδικασία της αναδιάρθρωσης του υπάρχοντος κωδικού υπολογιστών που αλλάζει τον factoring-χωρίς να αλλάζει την εξωτερική του συμπεριφορά.

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

Ένας άλλος λόγος που μπορεί να σκεφτεί κανείς ότι δεν είναι πραγματικός κώδικας είναι ότι κάνετε παραδείγματα όπου το τελικό πρόγραμμα μπορεί ήδη να σας επιβάλλει. Αυτό είναι πολύ καλό, όπως δείχνει Έχετε γνώση σχετικά με τον domain στον οποίο προγραμματίζετε.
Αλλά πολλές φορές οι προγραμματιστές βρίσκονται σε έναν domain που είναι new , unknown σε αυτούς. Δεν γνωρίζουν ποιο θα είναι το τελικό αποτέλεσμα και το TDD είναι μια technique για να γράφουμε βήμα προς βήμα τα προγράμματα, τεκμηριώντας τις knowledge μας για το πώς πρέπει να λειτουργήσει αυτό το σύστημα και να επαληθεύσουμε ότι ο κώδικας μας λειτουργεί με αυτόν τον τρόπο.

Όταν διάβασα το βιβλίο (*) στο TDD, για μένα το πιο σημαντικό χαρακτηριστικό που ξεχώριζε ήταν ο κατάλογος TODO. Μου έδειξε ότι το TDD είναι επίσης μια τεχνική που βοηθά τους προγραμματιστές να επικεντρωθούν σε ένα πράγμα τη φορά. Έτσι, αυτό είναι επίσης μια απάντηση στην ερώτησή σας aboout How much Real code to write ; Θα έλεγα αρκετό κώδικα για να επικεντρωθώ σε ένα πράγμα τη φορά.

(*) "Ανάπτυξη υπό δοκιμή: με παράδειγμα" από τον Kent Beck

1 comments
2 Robert Andrzejuk 07/27/2017
"Δοκιμασμένη Ανάπτυξη: Με Παράδειγμα" από τον Kent Beck

Zenilogix 07/31/2017.

Δεν γράφετε κώδικα για να αποτύχετε τα τεστ σας.

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

Το όλο θέμα σχετικά με το γράψιμο των δοκιμών αρχικής αποτυχίας είναι να κάνουν δύο πράγματα:

  1. Καλύψτε όλες τις περιπτώσεις - όλες τις ονομαστικές περιπτώσεις, όλες τις ακραίες περιπτώσεις κ.λπ.
  2. Επικυρώστε τις δοκιμές σας. Αν τους βλέπετε ποτέ να περάσουν, πώς μπορείτε να είστε βέβαιοι ότι θα αναφέρουν αξιόπιστα μια αποτυχία όταν συμβεί;

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

Στη δική μου εμπειρία (C # /. NET), η καθαρή πρώτη δοκιμή είναι ένα κομμάτι ενός ανέφικτου ιδεώδους, επειδή δεν μπορείτε να συντάξετε μια κλήση σε μια μέθοδο που δεν υπάρχει ακόμα. Επομένως, η "πρώτη δοκιμή" αφορά στην κωδικοποίηση των διεπαφών και των υλοποιήσεων, στη συνέχεια, γράφοντας τις δοκιμές κατά των πασσάλων (οι οποίες αρχικά αποτυγχάνουν) έως ότου τα σωληνάρια σφραγιστούν σωστά. Δεν γράφω ποτέ "αποτυχημένο κώδικα", απλώς χτίζοντας έξω από stubs.


Zan Lynx 07/27/2017.

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

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

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

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

Εκεί δοκιμάζετε τον "πραγματικό κώδικα".

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

1 comments
Peter Mortensen 07/27/2017
(το = κτητικό, είναι = "είναι" ή "έχει" .Βλέπε για παράδειγμα τον How to Use Its and It's .)

user3791372 07/27/2017.

Σε απάντηση στον τίτλο της ερώτησης: "Πότε γράφετε τον" πραγματικό "κώδικα στο TDD;", η απάντηση είναι: "σχεδόν ποτέ" ή "πολύ αργά".

Ακούγεται σαν φοιτητής, γι 'αυτό θα απαντήσω σαν να συμβουλεύω έναν μαθητή.

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

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

Αλλά πρέπει να ξέρετε πώς να σπάσετε την αίτησή σας για να μπορέσετε να σχεδιάσετε αξιοπρεπή κώδικα. Για παράδειγμα, εάν δεν γνωρίζατε για το Little Bobby Table (xkcd 327), τότε πιθανότατα δεν θα καθαρίζετε τις εισροές σας πριν εργαστείτε με τη βάση δεδομένων, οπότε δεν θα είστε σε θέση να εξασφαλίσετε τα δεδομένα σας γύρω από αυτή την έννοια.

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

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

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

5 comments
3 johnny 07/25/2017
Δεν είμαι καν κοντά σε φοιτητή, αλλά διαβάζω και προσπαθώ να εφαρμόσω καλές τεχνικές και να είμαι επαγγελματίας. Έτσι, με αυτή την έννοια, είμαι "μαθητής". Απλώς ρωτώ πολύ βασικά ερωτήματα γιατί έτσι είμαι. Μου αρέσει να ξέρω ακριβώς γιατί κάνω αυτό που κάνω. Η ουσία του θέματος. Εάν δεν το καταλάβω, δεν μου αρέσει και να αρχίσω να θέτω ερωτήσεις. Πρέπει να ξέρω γιατί, αν το θ 'χρησιμοποιήσω. Το TDD φαίνεται διαισθητικά καλό με διάφορους τρόπους, όπως το να γνωρίζει κανείς τι πρέπει να δημιουργήσετε και να σκεφτείτε τα πράγματα, αλλά η εφαρμογή ήταν δύσκολο να κατανοηθεί. Νομίζω ότι έχω καλύτερη κατανόηση τώρα.
4 Sean Burton 07/27/2017
Αυτοί είναι οι κανόνες του TDD. Είστε ελεύθεροι να γράψετε κώδικα, ωστόσο θέλετε, αλλά αν δεν ακολουθήσετε αυτούς τους τρεις κανόνες, δεν κάνετε TDD.
2 user3791372 07/27/2017
"Κανόνες" ενός ατόμου; Το TDD είναι μια πρόταση που θα σας βοηθήσει να κωδικοποιήσετε, όχι μια θρησκεία. Είναι λυπηρό το γεγονός ότι τόσοι πολλοί άνθρωποι προσκολλώνται σε μια ιδέα τόσο αληθινά. Ακόμα και η προέλευση του TDD είναι αμφιλεγόμενη.
2 Alex 07/28/2017
@ user3791372 Το TDD είναι μια πολύ αυστηρή και σαφώς καθορισμένη διαδικασία. Ακόμα κι αν πολλοί σκέφτονται ότι σημαίνει απλώς "Κάνετε κάποιες δοκιμές όταν προγραμματίζετε", δεν είναι. Ας προσπαθήσουμε να μην συγχέουμε τους όρους εδώ, αυτή η ερώτηση αφορά τη διαδικασία TDD, όχι γενικές δοκιμές.

Related questions

Hot questions

Language

Popular Tags