Εισαγωγή στη δοκιμή συμβολαίου με παραδείγματα

introduction contract testing with examples

Αυτό το σεμινάριο Pact Contract Testing εξηγεί τι είναι ο Έλεγχος συμβολαίου βάσει καταναλωτών, πώς λειτουργεί και γιατί πρέπει να το χρησιμοποιήσετε στη στρατηγική δοκιμών σας:

Τι είναι ο έλεγχος συμβολαίου;

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

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

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

Τι θα μάθετε:

• Λίστα εκπαιδευτικών σε αυτήν τη σειρά δοκιμών συμβολαίου
• Δοκιμή συμβολαίου βάσει καταναλωτή
  • Πώς λειτουργεί
  • Ρόλοι και ευθύνες
• Δοκιμή συμβολαίου Vs Integration Testing
  • Μερικά οφέλη (εάν δεν έχετε ήδη πουλήσει)
  • Συχνές Ερωτήσεις
• Συνεχής ενσωμάτωση
• συμπέρασμα
  • Συνιστώμενη ανάγνωση

Λίστα εκπαιδευτικών σε αυτήν τη σειρά δοκιμών συμβολαίου

Εκμάθηση # 1: Εισαγωγή στη δοκιμή συμβολαίου με παραδείγματα (Αυτό το σεμινάριο)
Εκμάθηση # 2: Πώς να γράψετε μια δοκιμαστική συμφωνία καταναλωτή σε JavaScript
Εκμάθηση # 3: Πώς να δημοσιεύσετε συμβόλαιο Pact στο Pact Broker
Εκμάθηση # 4: Επαληθεύστε τη Σύμβαση Συμφώνου και τη Συνεχή Ανάπτυξη με το Σύμφωνο CLI

Δοκιμή συμβολαίου βάσει καταναλωτή

Το σημείο εκκίνησης είναι η τεκμηρίωση API που αποτελεί το συμβόλαιο για τις δοκιμές σας, σε αυτό το σημείο συνήθως, οι ομάδες ανάπτυξης λαμβάνουν το έγγραφο API και αναπτύσσονται έναντι του εγγράφου wiki (ή οποιασδήποτε μορφής βρίσκεται στον οργανισμό σας, όπως το Word Document).

Για παράδειγμα, μια εφαρμογή Ιστού όπου το front-end αναπτύσσεται από την Team Krypton και το API αναπτύσσεται από την Team Thoron. Το έργο ξεκινά με μια εναρκτήρια συνάντηση όπου οι απαιτήσεις παρουσιάζονται και συμφωνούνται μεταξύ των ομάδων.

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

Οι δοκιμαστικές περιπτώσεις προστίθενται από την Team Thoron σχετικά με τα ενημερωμένα σενάρια με βάση την τεκμηρίωση.

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

1. Οι αλλαγές εγγράφων API ενδέχεται να μην κοινοποιούνται αποτελεσματικά.
2. Η ομάδα front-end αποκλείει το back-end service και το αντίστροφο.
3. Η ομάδα back-end δημιουργεί δοκιμαστικές περιπτώσεις ενσωμάτωσης βάσει τεκμηρίωσης.
4. Το περιβάλλον ολοκλήρωσης είναι η πρώτη φορά που δοκιμάζεται η πλήρης ολοκλήρωση.
5. Διαφορετική έκδοση API για περιβάλλον ολοκλήρωσης έναντι παραγωγής.

Ο έλεγχος συμβάσεων που βασίζεται στον καταναλωτή έχει δύο πλευρές, δηλαδή τον καταναλωτή και τον πάροχο. Αυτό είναι όπου η παραδοσιακή σκέψη σχετικά με τις δοκιμές σε μικροϋπηρεσίες ανατρέπεται.

ο Καταναλωτής είναι ο επιμελητής των σεναρίων, συμπεριλαμβανομένου του αιτήματος και της αναμενόμενης απόκρισης. Αυτό σας επιτρέπει να ακολουθήσετε Ο νόμος του κρεβατιού που υπαγορεύει ότι πρέπει να είστε ευέλικτοι σε ό, τι μπορεί να αποδεχτεί το API σας αλλά συντηρητικό σε ό, τι αποστέλλεται. Αναφερόμενοι στα ελαττώματα αρ. 1, 3 και 4, οι αλλαγές τεκμηρίωσης καθοδηγούνται από τον καταναλωτή.

Για παράδειγμα, στην περίπτωση που η ομάδα Thoron αλλάζει ένα πεδίο συμβολοσειράς για να μην αποδεχθεί μηδενικές τιμές, οι δοκιμές καταναλωτών δεν θα αντικατοπτρίζουν την αλλαγή και επομένως θα αποτύχουν. Ή τουλάχιστον μέχρι να γίνουν οι αλλαγές στο Team Krypton.

(εικόνα πηγή )

ο Προμηθευτής επαληθεύει τα σενάρια που παρέχονται από τον καταναλωτή σε σχέση με το περιβάλλον 'dev' τους. Αυτό επιτρέπει στις μικροϋπηρεσίες σας να εφαρμοστούν Παράλληλη αλλαγή το οποίο δηλώνει ότι πρέπει να επεκτείνετε τη λειτουργικότητα API, ακολουθούμενη από μετεγκατάσταση σε μια νέα έκδοση. Αναφερόμενος στο ελάττωμα αρ. 2, τα stubs που συνήθως δημιουργούνται από τις ομάδες back-end για τις δικές τους απαιτήσεις δοκιμών μπορούν τώρα να βασίζονται σε σενάρια καταναλωτών χρησιμοποιώντας Διακομιστής Pact Stub .

Το δεσμευτικό στοιχείο των δύο πλευρών είναι το «συμβόλαιο» που πρέπει να μοιραστεί μεταξύ των ομάδων. Το σύμφωνο παρέχει μια πλατφόρμα που επιτρέπει την κοινή χρήση συμβολαίων που ονομάζεται Μεσίτης Συμφώνων (διατίθεται ως διαχειριζόμενη υπηρεσία με Pactflow.io ).

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

Ένα πρόσθετο όφελος για το Pact Broker στις παλαιότερες πλατφόρμες είναι η προβολή των καταναλωτών. Δεν είναι όλοι οι καταναλωτές γνωστοί στους συγγραφείς του API, ειδικά δεν είναι πώς καταναλώνεται.

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

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

Πώς λειτουργεί

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

Η δοκιμή Καταναλωτή δημιουργεί ένα αίτημα POST για ένα διακριτικό περνώντας το σώμα με το όνομα χρήστη και τον κωδικό πρόσβασης.

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

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

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

Ρόλοι και ευθύνες

Διασφάλιση ποιότητας (QA) / Δοκιμαστής: Δημιουργία συμβολαίων χρησιμοποιώντας το Pact.io και συνεργασία με το BA για τη δημιουργία δοκιμαστικών σεναρίων.

Προγραμματιστής: Σύζευξη με τα QA για τη δημιουργία των δοκιμών και τη συμβολή στο API για υλοποίηση στο Continuous Integration (CI).

Επιχειρηματικός αναλυτής (BA): Δημιουργία σεναρίων και συνεργασία με τον αρχιτέκτονα για την επαλήθευση των εμπλεκόμενων μερών.

Αρχιτέκτονας λύσης (Ενδέχεται να μην υπάρχει στον οργανισμό σας): Ενεργοποίηση των αλλαγών API και συντονισμός με το BA κατά την εφαρμογή, επικοινωνώντας επίσης αλλαγές στους καταναλωτές (χρησιμοποιώντας το Pact Broker για να κατανοήσουμε ποιος μπορεί να αφορά).

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

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

Δοκιμή συμβολαίου Vs Integration Testing

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

Ο αντίκτυπος αυτού θα μπορούσε να είναι:

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

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

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

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

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

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

Μερικά οφέλη (εάν δεν έχετε ήδη πουλήσει)

Παρατίθενται παρακάτω μερικά από τα οφέλη που μπορείτε να αντλήσετε κατά την πώληση δοκιμών συμβολαίου στην ευρύτερη επιχείρηση:

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

Συχνές Ερωτήσεις

Μερικές κοινές ερωτήσεις ενώ προσπαθούν να πείσουν τους ανθρώπους να υιοθετήσουν δοκιμές συμβολαίου περιλαμβάνουν:

Ε # 1) Έχουμε ήδη 100% δοκιμαστική κάλυψη, οπότε δεν το χρειαζόμαστε.

Απάντηση: Λοιπόν αυτό είναι αδύνατο, αλλά η δοκιμή συμβολαίων έχει πολλά άλλα οφέλη εκτός από την κάλυψη δοκιμών

Ε # 2) Είναι ευθύνη του Αρχιτέκτονα Λύσης να κοινοποιεί τις αλλαγές API.

Απάντηση: Η ποιότητα είναι ευθύνη ολόκληρης της ομάδας.

Ε # 3) Γιατί δημιουργούμε δοκιμαστικά σενάρια για την ομάδα API;

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

Q # 4) Οι δοκιμές end-to-end καλύπτουν ολόκληρη τη ροή από την αρχή έως το τέλος, συμπεριλαμβανομένων άλλων σημείων ολοκλήρωσης.

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

Ε # 5) Σε ποιο αποθετήριο της ομάδας ζουν οι δοκιμές;

Απάντηση: Και τα δυο. Ο καταναλωτής στο αποθετήριό του και ο Παροχέας στο δικό τους. Στη συνέχεια, στο κεντρικό σημείο, η σύμβαση ζει έξω από κανένα από αυτά.

Επιχειρήματα

Αυτά είναι τα επιχειρήματα που δυσκολεύουμε να αμφισβητήσουμε όταν πρόκειται για μετάβαση σε συμβόλαιο για δοκιμή:

• Υπάρχει ήδη τεκμηρίωση Swagger που μπορεί να χρησιμοποιηθεί για τη δημιουργία δοκιμών ενοποίησης.
• Οι ομάδες κατέχουν υπηρεσίες front-end και back-end με έναν αποτελεσματικό μηχανισμό για αλλαγές API.

Συνεχής ενσωμάτωση

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

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

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

(εικόνα πηγή )

συμπέρασμα

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

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

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

ΕΠΟΜΕΝΟ Φροντιστήριο

Συνιστώμενη ανάγνωση

• Πώς να γράψετε μια δοκιμαστική συμφωνία καταναλωτή σε JavaScript
• Επαληθεύστε τη Σύμβαση Συμφώνου και τη Συνεχή Ανάπτυξη με το Σύμφωνο CLI
• Πώς να δημοσιεύσετε συμβόλαιο Pact στο Pact Broker
• Διαδικασία συνεχούς ενοποίησης: Πώς να βελτιώσετε την ποιότητα του λογισμικού και να μειώσετε τον κίνδυνο
• Οι διαφορές μεταξύ δοκιμών μονάδας, δοκιμών ολοκλήρωσης και δοκιμών λειτουργίας
• Τι είναι ο Έλεγχος Ενσωμάτωσης (Tutorial with Integration Test παράδειγμα)
• Κορυφαία 10 εργαλεία δοκιμών ενοποίησης για τη σύνταξη δοκιμών ενοποίησης
• Συνεχής ανάπτυξη σε DevOps