Πώς θα πρέπει να δοκιμάσω μονάδα κώδικα γεννήτρια;

ψήφοι
23

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

Έχω αναπτύξει έναν κώδικα-γεννήτρια που παίρνει διεπαφή Python μας σε C κώδικα μας ++ (που παράγεται μέσω SWIG) και δημιουργεί κώδικα που απαιτείται για να εκθέσει αυτό ως WebServices. Όταν αναπτύσσεται αυτόν τον κώδικα έκανα χρήση TDD, αλλά έχω βρεθεί δοκιμές μου να είναι εύθραυστα σαν κόλαση. Επειδή κάθε τεστ ουσιαστικά ήθελε να βεβαιωθείτε ότι για ένα συγκεκριμένο κομμάτι του κώδικα εισόδου (που συμβαίνει να είναι μια κεφαλίδα C ++) θα έπαιρνα ένα συγκεκριμένο κομμάτι της εξάγονται κωδικό έγραψα ένα μικρό κινητήρα που διαβάζει τους ορισμούς της δοκιμής από τα αρχεία εισόδου XML και δημιουργεί τεστ περιπτώσεις από αυτές τις προσδοκίες.

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

Γι 'αυτό και προσπαθώ να σκεφτώ εναλλακτικές προσεγγίσεις σε αυτό το πρόβλημα, και μου φαίνεται ότι είμαι ίσως η αντιμετώπιση με λάθος τρόπο. Ίσως θα πρέπει να επικεντρωθεί περισσότερο στο αποτέλεσμα, IE: δεν τον κώδικα που παράγουν πραγματικά να τρέξει και να κάνει ό, τι θέλω να, όχι, δεν το κωδικό δούμε τον τρόπο που θέλετε να.

Έχει κανείς έχεις καμία εμπειρία από κάτι παρόμοιο με αυτό που θα φροντίσει να μοιραστείτε;

Δημοσιεύθηκε 14/08/2008 στις 14:59
πηγή χρήστη
Σε άλλες γλώσσες...                            


8 απαντήσεις

ψήφοι
12

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

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

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

Απαντήθηκε 14/08/2008 στις 15:04
πηγή χρήστη

ψήφοι
0

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

Απαντήθηκε 14/08/2008 στις 15:38
πηγή χρήστη

ψήφοι
0

Αν τρέχετε σε * Nux θα μπορούσε να εξετάσει το ντάμπινγκ το unittest πλαίσιο υπέρ μιας bash script ή Makefile. σχετικά με τα παράθυρα θα μπορούσε να εξετάσει την οικοδόμηση ενός κελύφους εφαρμογή / λειτουργία που εκτελεί τη γεννήτρια και στη συνέχεια χρησιμοποιεί τον κωδικό (όπως μια άλλη διαδικασία) και unittest αυτό.

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

Απαντήθηκε 14/08/2008 στις 16:46
πηγή χρήστη

ψήφοι
5

Υπενθυμίζουμε ότι «δοκιμές μονάδα» είναι μόνο ένα είδος των δοκιμών. Θα πρέπει να είναι σε θέση να δοκιμή μονάδα τα εσωτερικά τμήματα της γεννήτριας κώδικα σας. Αυτό που πραγματικά κοιτάζοντας εδώ είναι ο έλεγχος του επιπέδου του συστήματος (γνωστός και ως δοκιμές παλινδρόμησης). Δεν είναι μόνο σημασιολογίας ... υπάρχουν διαφορετικές νοοτροπίες, προσεγγίσεις, τις προσδοκίες, κ.λπ. Είναι σίγουρα περισσότερη δουλειά, αλλά ίσως χρειαστεί να επιμείνει στις προσπάθειές της και να δημιουργήσει ένα end-to-end σουίτα ελέγχου αναδρομής: σταθερά C ++ αρχεία -> SWIG διεπαφές -> modules πύθωνα -> γνωστό εξόδου. Είστε σίγουροι ότι θέλετε να ελέγξετε τη γνωστή εισόδου (σταθερά C ++ κώδικα) έναντι αναμενόμενο αποτέλεσμα (αυτό που βγαίνει από το τελικό πρόγραμμα Python). Έλεγχος των αποτελεσμάτων γεννήτρια κώδικα άμεσα θα είναι όπως ψάχνοντας για διαφορές αρχεία αντικείμενο ...

Απαντήθηκε 14/08/2008 στις 19:15
πηγή χρήστη

ψήφοι
0

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

int x = 0;
GENERATED_CODE
assert(x == 100);

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

Απαντήθηκε 16/09/2008 στις 10:41
πηγή χρήστη

ψήφοι
0

Μονάδα δοκιμών είναι ακριβώς αυτό δοκιμασία συγκεκριμένης μονάδας. Έτσι, εάν γράφετε μια προδιαγραφή για την κατηγορία Α, είναι ιδανικό εάν κατηγορίας Α δεν έχει τις πραγματικές συγκεκριμένες εκδόσεις της κατηγορίας Β και C.

Εντάξει παρατήρησα μετά την ετικέτα για το ζήτημα αυτό περιλαμβάνει C ++ / Python, αλλά οι αρχές είναι οι ίδιες:

    public class A : InterfaceA 
    {   
      InterfaceB b;

      InterfaceC c;

      public A(InterfaceB b, InterfaceC c)   {
          this._b = b;
          this._c = c;   }

      public string SomeOperation(string input)   
      {
          return this._b.SomeOtherOperation(input) 
               + this._c.EvenAnotherOperation(input); 
      } 
    }

Επειδή η παραπάνω Σύστημα Α διοχετεύει διασυνδέσεις με συστήματα Β και Γ, μπορείτε να πειραματική μονάδα μόνο σύστημα Α, χωρίς να έχει πραγματική λειτουργία που εκτελείται από οποιοδήποτε άλλο σύστημα. Αυτό είναι δοκιμές μονάδα.

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

public class When_system_A_has_some_operation_called_with_valid_input : SystemASpecification
{
    private string _actualString;

    private string _expectedString;

    private string _input;

    private string _returnB;

    private string _returnC;

    [It]
    public void Should_return_the_expected_string()
    {
        _actualString.Should().Be.EqualTo(this._expectedString);
    }

    public override void GivenThat()
    {
        var randomGenerator = new RandomGenerator();
        this._input = randomGenerator.Generate<string>();
        this._returnB = randomGenerator.Generate<string>();
        this._returnC = randomGenerator.Generate<string>();

        Dep<InterfaceB>().Stub(b => b.SomeOtherOperation(_input))
                         .Return(this._returnB);
        Dep<InterfaceC>().Stub(c => c.EvenAnotherOperation(_input))
                         .Return(this._returnC);

        this._expectedString = this._returnB + this._returnC;
    }

    public override void WhenIRun()
    {
        this._actualString = Sut.SomeOperation(this._input);
    }
}

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

Απαντήθηκε 20/05/2010 στις 00:17
πηγή χρήστη

ψήφοι
0

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

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

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

Απαντήθηκε 26/07/2010 στις 00:56
πηγή χρήστη

ψήφοι
0

Θεωρώ ότι θα πρέπει να δοκιμάσετε αυτό που παράγει περισσότερο από το πώς μπορείτε να δημιουργήσετε.

Στην περίπτωσή μου, το πρόγραμμα δημιουργεί πολλούς τύπους κώδικα (C #, HTML, SCSS, JS, κλπ) που συγκεντρώνουν σε μια εφαρμογή web. Ο καλύτερος τρόπος που έχω βρεθεί για τη μείωση των σφαλμάτων παλινδρόμησης συνολικά είναι να δοκιμάσει το ίδιο το web εφαρμογή, όχι με τον έλεγχο της γεννήτριας.

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

Επειδή είμαστε το παράγουν θα δημιουργήσει επίσης ένα ωραίο άντληση JS μπορούμε να χρησιμοποιήσουμε για να ελέγξετε κάποιου προγράμματος την εφαρμογή. Ακολουθήσαμε μερικές ιδέες που περιγράφονται εδώ: http://code.tutsplus.com/articles/maintainable-automated-ui-tests--net-35089

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

Είναι πολύ γλυκό.

Καλή τύχη!

Απαντήθηκε 20/07/2015 στις 04:10
πηγή χρήστη

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more