Σε έργα που σχετίζονται με την ανάπτυξη της αρχιτεκτονικής μικροϋπηρεσιών, το CI/CD μετακινείται από την κατηγορία της ευχάριστης ευκαιρίας στην κατηγορία της επείγουσας ανάγκης. Οι αυτοματοποιημένες δοκιμές αποτελούν αναπόσπαστο μέρος της συνεχούς ολοκλήρωσης, μια ικανή προσέγγιση στην οποία μπορεί να προσφέρει στην ομάδα πολλές ευχάριστες βραδιές με την οικογένεια και τους φίλους. Διαφορετικά, το έργο κινδυνεύει να μην ολοκληρωθεί ποτέ.
Είναι δυνατό να καλυφθεί ολόκληρος ο κώδικας microservice με δοκιμές μονάδας με εικονικά αντικείμενα, αλλά αυτό λύνει μόνο εν μέρει το πρόβλημα και αφήνει πολλές ερωτήσεις και δυσκολίες, ειδικά κατά τη δοκιμή εργασίας με δεδομένα. Όπως πάντα, οι πιο πιεστικοί είναι ο έλεγχος της συνέπειας δεδομένων σε μια σχεσιακή βάση δεδομένων, ο έλεγχος της εργασίας με υπηρεσίες cloud και οι εσφαλμένες υποθέσεις κατά τη σύνταξη εικονικών αντικειμένων.
Όλα αυτά και λίγα περισσότερα μπορούν να λυθούν δοκιμάζοντας ολόκληρη τη microservice σε ένα δοχείο Docker. Ένα αναμφισβήτητο πλεονέκτημα για τη διασφάλιση της εγκυρότητας των δοκιμών είναι ότι δοκιμάζονται οι ίδιες εικόνες Docker που βγαίνουν στην παραγωγή.
Η αυτοματοποίηση αυτής της προσέγγισης παρουσιάζει μια σειρά προβλημάτων, η λύση των οποίων θα περιγραφεί παρακάτω:
- συγκρούσεις παράλληλων εργασιών στον ίδιο κεντρικό υπολογιστή βάσης.
- διενέξεις αναγνωριστικών στη βάση δεδομένων κατά τη διάρκεια των δοκιμαστικών επαναλήψεων.
- περιμένοντας να είναι έτοιμες οι μικροϋπηρεσίες.
- συγχώνευση και έξοδος αρχείων καταγραφής σε εξωτερικά συστήματα.
- δοκιμή εξερχόμενων αιτημάτων HTTP.
- Δοκιμή διαδικτυακής υποδοχής (χρησιμοποιώντας SignalR).
- δοκιμή ελέγχου ταυτότητας και εξουσιοδότησης OAuth.
Αυτό το άρθρο βασίζεται σε στο SECR 2019. Για όσους τεμπελιάζουν λοιπόν να διαβάσουν, .
Σε αυτό το άρθρο θα σας πω πώς να χρησιμοποιήσετε ένα σενάριο για να εκτελέσετε την υπηρεσία υπό δοκιμή, μια βάση δεδομένων και τις υπηρεσίες Amazon AWS στο Docker, στη συνέχεια δοκιμές στο Postman και, αφού ολοκληρωθούν, να σταματήσετε και να διαγράψετε τα δημιουργημένα κοντέινερ. Οι δοκιμές εκτελούνται κάθε φορά που αλλάζει ο κώδικας. Με αυτόν τον τρόπο, διασφαλίζουμε ότι κάθε έκδοση λειτουργεί σωστά με τη βάση δεδομένων και τις υπηρεσίες AWS.
Το ίδιο σενάριο εκτελείται τόσο από τους ίδιους τους προγραμματιστές στους επιτραπέζιους υπολογιστές Windows όσο και από τον διακομιστή Gitlab CI στο Linux.
Για να δικαιολογηθεί, η εισαγωγή νέων δοκιμών δεν θα πρέπει να απαιτεί την εγκατάσταση πρόσθετων εργαλείων είτε στον υπολογιστή του προγραμματιστή είτε στον διακομιστή όπου οι δοκιμές εκτελούνται σε μια δέσμευση. Το Docker επιλύει αυτό το πρόβλημα.
Η δοκιμή πρέπει να εκτελείται σε τοπικό διακομιστή για τους ακόλουθους λόγους:
- Το δίκτυο δεν είναι ποτέ απολύτως αξιόπιστο. Από χίλια αιτήματα, ένα μπορεί να αποτύχει.
Σε αυτήν την περίπτωση, η αυτόματη δοκιμή δεν θα λειτουργήσει, η εργασία θα σταματήσει και θα πρέπει να αναζητήσετε τον λόγο στα αρχεία καταγραφής. - Τα υπερβολικά συχνά αιτήματα δεν επιτρέπονται από ορισμένες υπηρεσίες τρίτων.
Επιπλέον, δεν είναι επιθυμητή η χρήση της βάσης επειδή:
- Μια βάση μπορεί να σπάσει όχι μόνο από κακό κώδικα που εκτελείται σε αυτό, αλλά και από δεδομένα που ο σωστός κώδικας δεν μπορεί να επεξεργαστεί.
- Ανεξάρτητα από το πόσο σκληρά προσπαθούμε να επαναφέρουμε όλες τις αλλαγές που έγιναν από το τεστ κατά τη διάρκεια του ίδιου του τεστ, κάτι μπορεί να πάει στραβά (αλλιώς, γιατί να δοκιμάσετε;).
Σχετικά με το έργο και την οργάνωση της διαδικασίας
Η εταιρεία μας ανέπτυξε μια εφαρμογή web microservice που εκτελείται στο Docker στο Amazon AWS cloud. Οι δοκιμές μονάδας χρησιμοποιήθηκαν ήδη στο έργο, αλλά συχνά εμφανίζονταν σφάλματα που δεν εντόπισαν οι δοκιμές μονάδας. Ήταν απαραίτητο να δοκιμαστεί μια ολόκληρη microservice μαζί με τη βάση δεδομένων και τις υπηρεσίες Amazon.
Το έργο χρησιμοποιεί μια τυπική διαδικασία συνεχούς ολοκλήρωσης, η οποία περιλαμβάνει τη δοκιμή της microservice με κάθε δέσμευση. Μετά την ανάθεση μιας εργασίας, ο προγραμματιστής κάνει αλλαγές στην microservice, τη δοκιμάζει χειροκίνητα και εκτελεί όλες τις διαθέσιμες αυτοματοποιημένες δοκιμές. Εάν είναι απαραίτητο, ο προγραμματιστής αλλάζει τις δοκιμές. Εάν δεν εντοπιστούν προβλήματα, γίνεται δέσμευση στον κλάδο αυτού του τεύχους. Μετά από κάθε δέσμευση, οι δοκιμές εκτελούνται αυτόματα στον διακομιστή. Η συγχώνευση σε έναν κοινό κλάδο και η έναρξη αυτόματων δοκιμών σε αυτό πραγματοποιείται μετά από επιτυχή αναθεώρηση. Εάν οι δοκιμές στο κοινόχρηστο υποκατάστημα περάσουν, η υπηρεσία ενημερώνεται αυτόματα στο περιβάλλον δοκιμής στο Amazon Elastic Container Service (πάγκος). Το περίπτερο είναι απαραίτητο για όλους τους προγραμματιστές και τους δοκιμαστές και δεν συνιστάται να το σπάσετε. Οι δοκιμαστές σε αυτό το περιβάλλον ελέγχουν μια επιδιόρθωση ή μια νέα δυνατότητα εκτελώντας μη αυτόματους ελέγχους.
Αρχιτεκτονική έργου
Η εφαρμογή αποτελείται από περισσότερες από δέκα υπηρεσίες. Μερικά από αυτά είναι γραμμένα σε .NET Core και άλλα σε NodeJs. Κάθε υπηρεσία εκτελείται σε ένα κοντέινερ Docker στην υπηρεσία Amazon Elastic Container Service. Το καθένα έχει τη δική του βάση δεδομένων Postgres και μερικά έχουν επίσης Redis. Δεν υπάρχουν κοινές βάσεις δεδομένων. Εάν πολλές υπηρεσίες χρειάζονται τα ίδια δεδομένα, τότε αυτά τα δεδομένα, όταν αλλάζουν, μεταδίδονται σε καθεμία από αυτές τις υπηρεσίες μέσω SNS (Simple Notification Service) και SQS (Amazon Simple Queue Service) και οι υπηρεσίες τα αποθηκεύουν στις δικές τους ξεχωριστές βάσεις δεδομένων.
SQS και SNS
Το SQS σάς επιτρέπει να τοποθετείτε μηνύματα σε μια ουρά και να διαβάζετε μηνύματα από την ουρά χρησιμοποιώντας το πρωτόκολλο HTTPS.
Εάν πολλές υπηρεσίες διαβάζουν μία ουρά, τότε κάθε μήνυμα φτάνει μόνο σε μία από αυτές. Αυτό είναι χρήσιμο όταν εκτελούνται πολλές παρουσίες της ίδιας υπηρεσίας για την κατανομή του φορτίου μεταξύ τους.
Εάν θέλετε κάθε μήνυμα να παραδίδεται σε πολλές υπηρεσίες, κάθε παραλήπτης πρέπει να έχει τη δική του ουρά και απαιτείται SNS για την αντιγραφή των μηνυμάτων σε πολλές ουρές.
Στο SNS δημιουργείτε ένα θέμα και εγγραφείτε σε αυτό, για παράδειγμα, μια ουρά SQS. Μπορείτε να στείλετε μηνύματα στο θέμα. Σε αυτήν την περίπτωση, το μήνυμα αποστέλλεται σε κάθε ουρά που έχει εγγραφεί σε αυτό το θέμα. Το SNS δεν διαθέτει μέθοδο για την ανάγνωση μηνυμάτων. Εάν κατά τη διάρκεια του εντοπισμού σφαλμάτων ή της δοκιμής πρέπει να μάθετε τι αποστέλλεται στο SNS, μπορείτε να δημιουργήσετε μια ουρά SQS, να την εγγραφείτε στο επιθυμητό θέμα και να διαβάσετε την ουρά.
API πύλη
Οι περισσότερες υπηρεσίες δεν είναι άμεσα προσβάσιμες από το Διαδίκτυο. Η πρόσβαση γίνεται μέσω του API Gateway, το οποίο ελέγχει τα δικαιώματα πρόσβασης. Αυτή είναι και η υπηρεσία μας, και υπάρχουν δοκιμές και γι' αυτήν.
Ειδοποιήσεις σε πραγματικό χρόνο
Η εφαρμογή χρησιμοποιεί για εμφάνιση ειδοποιήσεων σε πραγματικό χρόνο στον χρήστη. Αυτό εφαρμόζεται στην υπηρεσία ειδοποιήσεων. Είναι προσβάσιμο απευθείας από το Διαδίκτυο και λειτουργεί με το OAuth, επειδή αποδείχθηκε ότι δεν ήταν πρακτικό να δημιουργηθεί υποστήριξη για υποδοχές Web στο Gateway, σε σύγκριση με την ενσωμάτωση του OAuth και της υπηρεσίας ειδοποιήσεων.
Γνωστή Προσέγγιση Δοκιμών
Οι δοκιμές μονάδων αντικαθιστούν πράγματα όπως η βάση δεδομένων με εικονικά αντικείμενα. Εάν μια microservice, για παράδειγμα, προσπαθήσει να δημιουργήσει μια εγγραφή σε έναν πίνακα με ένα ξένο κλειδί και η εγγραφή που αναφέρεται από αυτό το κλειδί δεν υπάρχει, τότε το αίτημα δεν μπορεί να εκτελεστεί. Οι δοκιμές μονάδας δεν μπορούν να το εντοπίσουν.
В Προτείνεται η χρήση μιας βάσης δεδομένων στη μνήμη και η υλοποίηση εικονικών αντικειμένων.
Η βάση δεδομένων στη μνήμη είναι ένα από τα DBMS που υποστηρίζονται από το Entity Framework. Δημιουργήθηκε ειδικά για δοκιμή. Τα δεδομένα σε μια τέτοια βάση δεδομένων αποθηκεύονται μόνο μέχρι να τερματιστεί η διαδικασία που τη χρησιμοποιεί. Δεν απαιτεί τη δημιουργία πινάκων και δεν ελέγχει την ακεραιότητα των δεδομένων.
Τα εικονικά αντικείμενα μοντελοποιούν την κλάση που αντικαθιστούν μόνο στο βαθμό που ο προγραμματιστής δοκιμής κατανοεί πώς λειτουργεί.
Ο τρόπος με τον οποίο μπορείτε να ξεκινήσετε αυτόματα το Postgres και να εκτελεί μετεγκαταστάσεις όταν εκτελείτε μια δοκιμή δεν καθορίζεται στο άρθρο της Microsoft. Η λύση μου το κάνει αυτό και, επιπλέον, δεν προσθέτει κανέναν κωδικό ειδικά για δοκιμές στην ίδια την microservice.
Ας προχωρήσουμε στη λύση
Κατά τη διαδικασία ανάπτυξης, κατέστη σαφές ότι οι δοκιμές μονάδων δεν ήταν αρκετές για να βρεθούν όλα τα προβλήματα έγκαιρα, οπότε αποφασίστηκε να προσεγγιστεί αυτό το ζήτημα από διαφορετική οπτική γωνία.
Ρύθμιση περιβάλλοντος δοκιμής
Η πρώτη εργασία είναι η ανάπτυξη ενός δοκιμαστικού περιβάλλοντος. Βήματα που απαιτούνται για την εκτέλεση μιας microservice:
- Διαμορφώστε την υπό δοκιμή υπηρεσία για το τοπικό περιβάλλον, καθορίστε τις λεπτομέρειες για τη σύνδεση με τη βάση δεδομένων και το AWS στις μεταβλητές περιβάλλοντος.
- Ξεκινήστε το Postgres και εκτελέστε τη μετεγκατάσταση εκτελώντας το Liquibase.
Στα σχεσιακά DBMS, πριν γράψετε δεδομένα στη βάση δεδομένων, πρέπει να δημιουργήσετε ένα σχήμα δεδομένων, με άλλα λόγια, πίνακες. Κατά την ενημέρωση μιας εφαρμογής, οι πίνακες πρέπει να μεταφέρονται στη φόρμα που χρησιμοποιείται από τη νέα έκδοση και, κατά προτίμηση, χωρίς απώλεια δεδομένων. Αυτό ονομάζεται μετανάστευση. Η δημιουργία πινάκων σε μια αρχικά κενή βάση δεδομένων είναι μια ειδική περίπτωση μετεγκατάστασης. Η μετεγκατάσταση μπορεί να ενσωματωθεί στην ίδια την εφαρμογή. Τόσο το .NET όσο και το NodeJS διαθέτουν πλαίσια μετεγκατάστασης. Στην περίπτωσή μας, για λόγους ασφαλείας, οι μικροϋπηρεσίες στερούνται του δικαιώματος αλλαγής του σχήματος δεδομένων και η μετεγκατάσταση πραγματοποιείται χρησιμοποιώντας το Liquibase. - Εκκινήστε το Amazon LocalStack. Αυτή είναι μια εφαρμογή των υπηρεσιών AWS για εκτέλεση στο σπίτι. Υπάρχει μια έτοιμη εικόνα για το LocalStack στο Docker Hub.
- Εκτελέστε το σενάριο για να δημιουργήσετε τις απαραίτητες οντότητες στο LocalStack. Τα σενάρια Shell χρησιμοποιούν το AWS CLI.
Χρησιμοποιείται για δοκιμή στο έργο . Υπήρχε στο παρελθόν, αλλά κυκλοφόρησε χειροκίνητα και δοκίμασε μια εφαρμογή που είχε ήδη αναπτυχθεί στο περίπτερο. Αυτό το εργαλείο σάς επιτρέπει να κάνετε αυθαίρετα αιτήματα HTTP(S) και να ελέγχετε εάν οι απαντήσεις ταιριάζουν με τις προσδοκίες. Τα ερωτήματα συνδυάζονται σε μια συλλογή και μπορεί να εκτελεστεί ολόκληρη η συλλογή.
Πώς λειτουργεί το αυτόματο τεστ;
Κατά τη διάρκεια της δοκιμής, όλα λειτουργούν στο Docker: η υπηρεσία υπό δοκιμή, το Postgres, το εργαλείο μετεγκατάστασης και ο Postman, ή μάλλον η έκδοση της κονσόλας - Newman.
Το Docker επιλύει μια σειρά προβλημάτων:
- Ανεξαρτησία από τη διαμόρφωση κεντρικού υπολογιστή.
- Εγκατάσταση εξαρτήσεων: Το Docker πραγματοποιεί λήψη εικόνων από το Docker Hub.
- Επαναφορά του συστήματος στην αρχική του κατάσταση: απλά αφαιρέστε τα δοχεία.
Docker-compose ενώνει κοντέινερ σε ένα εικονικό δίκτυο, απομονωμένο από το Διαδίκτυο, στο οποίο τα κοντέινερ βρίσκουν το ένα το άλλο με ονόματα τομέα.
Η δοκιμή ελέγχεται από ένα σενάριο φλοιού. Για να εκτελέσουμε τη δοκιμή στα Windows χρησιμοποιούμε git-bash. Έτσι, ένα σενάριο αρκεί τόσο για Windows όσο και για Linux. Το Git και το Docker εγκαθίστανται από όλους τους προγραμματιστές του έργου. Κατά την εγκατάσταση του Git στα Windows, το git-bash είναι εγκατεστημένο, επομένως όλοι έχουν και αυτό.
Το σενάριο εκτελεί τα ακόλουθα βήματα:
- Δημιουργία εικόνων docker
docker-compose build - Εκκίνηση της βάσης δεδομένων και του LocalStack
docker-compose up -d <контейнер> - Μετακίνηση βάσης δεδομένων και προετοιμασία LocalStack
docker-compose run <контейнер> - Εκκίνηση της υπηρεσίας υπό δοκιμή
docker-compose up -d <сервис> - Εκτέλεση του τεστ (Newman)
- Διακοπή όλων των δοχείων
docker-compose down - Δημοσίευση αποτελεσμάτων στο Slack
Έχουμε μια συνομιλία όπου πηγαίνουν μηνύματα με πράσινο σημάδι επιλογής ή κόκκινο σταυρό και σύνδεσμο προς το αρχείο καταγραφής.
Οι ακόλουθες εικόνες Docker εμπλέκονται σε αυτά τα βήματα:
- Η υπηρεσία που δοκιμάζεται είναι η ίδια εικόνα με την παραγωγή. Η διαμόρφωση για τη δοκιμή γίνεται μέσω μεταβλητών περιβάλλοντος.
- Για τα Postgres, Redis και LocalStack, χρησιμοποιούνται έτοιμες εικόνες από το Docker Hub. Υπάρχουν επίσης έτοιμες εικόνες για το Liquibase και το Newman. Χτίζουμε τα δικά μας πάνω στον σκελετό τους, προσθέτοντας εκεί τα αρχεία μας.
- Για να προετοιμάσετε το LocalStack, χρησιμοποιείτε μια έτοιμη εικόνα AWS CLI και δημιουργείτε μια εικόνα που περιέχει ένα σενάριο που βασίζεται σε αυτήν.
Χρησιμοποιώντας , δεν χρειάζεται να δημιουργήσετε μια εικόνα Docker απλώς για να προσθέσετε αρχεία στο κοντέινερ. Ωστόσο, οι τόμοι δεν είναι κατάλληλοι για το περιβάλλον μας επειδή οι ίδιες οι εργασίες Gitlab CI εκτελούνται σε κοντέινερ. Μπορείτε να ελέγξετε το Docker από ένα τέτοιο κοντέινερ, αλλά οι τόμοι προσαρτούν φακέλους μόνο από το κεντρικό σύστημα και όχι από άλλο κοντέινερ.
Προβλήματα που μπορεί να αντιμετωπίσετε
Αναμονή για ετοιμότητα
Όταν εκτελείται ένα κοντέινερ με υπηρεσία, αυτό δεν σημαίνει ότι είναι έτοιμο να δεχτεί συνδέσεις. Πρέπει να περιμένετε να συνεχιστεί η σύνδεση.
Αυτό το πρόβλημα μερικές φορές επιλύεται χρησιμοποιώντας ένα σενάριο , το οποίο περιμένει μια ευκαιρία για να δημιουργήσει μια σύνδεση TCP. Ωστόσο, το LocalStack μπορεί να προκαλέσει ένα σφάλμα 502 Bad Gateway. Επιπλέον, αποτελείται από πολλές υπηρεσίες, και αν μια από αυτές είναι έτοιμη, αυτό δεν λέει τίποτα για τις άλλες.
Λύση: Σενάρια παροχής LocalStack που περιμένουν απόκριση 200 από SQS και SNS.
Παράλληλες διενέξεις εργασιών
Πολλές δοκιμές μπορούν να εκτελούνται ταυτόχρονα στον ίδιο κεντρικό υπολογιστή Docker, επομένως τα ονόματα κοντέινερ και δικτύου πρέπει να είναι μοναδικά. Επιπλέον, δοκιμές από διαφορετικούς κλάδους της ίδιας υπηρεσίας μπορούν επίσης να εκτελούνται ταυτόχρονα, επομένως δεν αρκεί να γράφετε τα ονόματά τους σε κάθε αρχείο σύνθεσης.
Λύση: Το σενάριο ορίζει τη μεταβλητή COMPOSE_PROJECT_NAME σε μια μοναδική τιμή.
Χαρακτηριστικά των Windows
Υπάρχουν πολλά πράγματα που θέλω να επισημάνω όταν χρησιμοποιείτε το Docker στα Windows, καθώς αυτές οι εμπειρίες είναι σημαντικές για την κατανόηση του γιατί συμβαίνουν σφάλματα.
- Τα σενάρια Shell σε ένα κοντέινερ πρέπει να έχουν καταλήξεις γραμμής Linux.
Το σύμβολο CR του κελύφους είναι συντακτικό σφάλμα. Είναι δύσκολο να καταλάβει κανείς από το μήνυμα σφάλματος ότι αυτό συμβαίνει. Όταν επεξεργάζεστε τέτοια σενάρια στα Windows, χρειάζεστε ένα κατάλληλο πρόγραμμα επεξεργασίας κειμένου. Επιπλέον, το σύστημα ελέγχου έκδοσης πρέπει να διαμορφωθεί σωστά.
Έτσι διαμορφώνεται το git:
git config core.autocrlf input- Το Git-bash προσομοιώνει τυπικούς φακέλους Linux και, κατά την κλήση ενός αρχείου exe (συμπεριλαμβανομένου του docker.exe), αντικαθιστά τις απόλυτες διαδρομές Linux με διαδρομές των Windows. Ωστόσο, αυτό δεν έχει νόημα για διαδρομές που δεν βρίσκονται στο τοπικό μηχάνημα (ή διαδρομές σε ένα κοντέινερ). Αυτή η συμπεριφορά δεν μπορεί να απενεργοποιηθεί.
Λύση: προσθέστε μια επιπλέον κάθετο στην αρχή της διαδρομής: //bin αντί για /bin. Το Linux κατανοεί τέτοιες διαδρομές· γι' αυτό, πολλές κάθετες είναι ίδιες με μία. Αλλά το git-bash δεν αναγνωρίζει τέτοια μονοπάτια και δεν προσπαθεί να τα μετατρέψει.
Έξοδος καταγραφής
Κατά την εκτέλεση δοκιμών, θα ήθελα να βλέπω αρχεία καταγραφής τόσο από τον Newman όσο και από την υπηρεσία που δοκιμάζεται. Δεδομένου ότι τα συμβάντα αυτών των αρχείων καταγραφής είναι διασυνδεδεμένα, ο συνδυασμός τους σε μία κονσόλα είναι πολύ πιο βολικός από δύο ξεχωριστά αρχεία. Ο Newman εκτοξεύεται μέσω docker-compose εκτέλεση, και έτσι η έξοδος του καταλήγει στην κονσόλα. Το μόνο που μένει είναι να βεβαιωθείτε ότι η έξοδος της υπηρεσίας πηγαίνει επίσης εκεί.
Η αρχική λύση ήταν να γίνει docker-συνθέστε επάνω καμία σημαία -d, αλλά χρησιμοποιώντας τις δυνατότητες του κελύφους, στείλτε αυτήν τη διαδικασία στο παρασκήνιο:
docker-compose up <service> &Αυτό λειτούργησε έως ότου χρειάστηκε η αποστολή αρχείων καταγραφής από το Docker σε μια υπηρεσία τρίτου μέρους. docker-συνθέστε επάνω σταμάτησε να εξάγει αρχεία καταγραφής στην κονσόλα. Ωστόσο, η ομάδα δούλεψε docker επισυνάπτω.
Λύση:
docker attach --no-stdin ${COMPOSE_PROJECT_NAME}_<сервис>_1 &Διένεξη αναγνωριστικού κατά τις δοκιμαστικές επαναλήψεις
Οι δοκιμές εκτελούνται σε πολλές επαναλήψεις. Η βάση δεδομένων δεν εκκαθαρίζεται. Οι εγγραφές στη βάση δεδομένων έχουν μοναδικά αναγνωριστικά. Εάν σημειώσουμε συγκεκριμένα αναγνωριστικά σε αιτήματα, θα λάβουμε διένεξη στη δεύτερη επανάληψη.
Για να το αποφύγετε, είτε τα αναγνωριστικά πρέπει να είναι μοναδικά είτε όλα τα αντικείμενα που δημιουργήθηκαν από τη δοκιμή πρέπει να διαγραφούν. Ορισμένα αντικείμενα δεν μπορούν να διαγραφούν λόγω απαιτήσεων.
Λύση: δημιουργία GUID χρησιμοποιώντας σενάρια Postman.
var uuid = require('uuid');
var myid = uuid.v4();
pm.environment.set('myUUID', myid);Στη συνέχεια χρησιμοποιήστε το σύμβολο στο ερώτημα {{myUUID}}, η οποία θα αντικατασταθεί με την τιμή της μεταβλητής.
Συνεργασία μέσω LocalStack
Εάν η υπηρεσία που ελέγχεται διαβάζει ή γράφει σε μια ουρά SQS, τότε για να επαληθευτεί αυτό, η ίδια η δοκιμή πρέπει επίσης να λειτουργεί με αυτήν την ουρά.
Λύση: αιτήματα από τον Ταχυδρόμο στο LocalStack.
Το API υπηρεσιών AWS είναι τεκμηριωμένο, επιτρέποντας τη διενέργεια ερωτημάτων χωρίς SDK.
Εάν μια υπηρεσία γράφει σε μια ουρά, τότε τη διαβάζουμε και ελέγχουμε τα περιεχόμενα του μηνύματος.
Εάν η υπηρεσία στέλνει μηνύματα στο SNS, στο στάδιο προετοιμασίας το LocalStack δημιουργεί επίσης μια ουρά και εγγράφεται σε αυτό το θέμα SNS. Στη συνέχεια, όλα καταλήγουν σε αυτό που περιγράφηκε παραπάνω.
Εάν η υπηρεσία χρειάζεται να διαβάσει ένα μήνυμα από την ουρά, τότε στο προηγούμενο βήμα δοκιμής γράφουμε αυτό το μήνυμα στην ουρά.
Δοκιμή αιτημάτων HTTP που προέρχονται από την υπό δοκιμή μικρουπηρεσία
Ορισμένες υπηρεσίες λειτουργούν μέσω HTTP με κάτι διαφορετικό από το AWS και ορισμένες δυνατότητες AWS δεν υλοποιούνται στο LocalStack.
Λύση: σε αυτές τις περιπτώσεις μπορεί να βοηθήσει , το οποίο έχει έτοιμη εικόνα στο . Τα αναμενόμενα αιτήματα και οι απαντήσεις σε αυτά διαμορφώνονται από ένα αίτημα HTTP. Το API είναι τεκμηριωμένο, επομένως κάνουμε αιτήματα από τον Postman.
Δοκιμή ελέγχου ταυτότητας και εξουσιοδότησης OAuth
Χρησιμοποιούμε το OAuth και . Η δοκιμή απαιτεί έναν πάροχο OAuth που μπορούμε να εκτελέσουμε τοπικά.
Όλες οι αλληλεπιδράσεις μεταξύ της υπηρεσίας και του παρόχου OAuth καταλήγουν σε δύο αιτήματα: πρώτον, ζητείται η διαμόρφωση /.γνωστό/openid-configuration, και στη συνέχεια ζητείται το δημόσιο κλειδί (JWKS) στη διεύθυνση από τη διαμόρφωση. Όλα αυτά είναι στατικό περιεχόμενο.
Λύση: Ο δοκιμαστικός πάροχος OAuth είναι ένας διακομιστής στατικού περιεχομένου και δύο αρχεία σε αυτόν. Το διακριτικό δημιουργείται μία φορά και δεσμεύεται στο Git.
Χαρακτηριστικά της δοκιμής SignalR
Ο Ταχυδρόμος δεν λειτουργεί με υποδοχές web. Δημιουργήθηκε ένα ειδικό εργαλείο για τη δοκιμή του SignalR.
Ένας πελάτης SignalR μπορεί να είναι κάτι περισσότερο από ένα πρόγραμμα περιήγησης. Υπάρχει μια βιβλιοθήκη πελάτη για αυτό στο .NET Core. Το πρόγραμμα-πελάτης, γραμμένο σε .NET Core, δημιουργεί μια σύνδεση, επαληθεύεται η ταυτότητα και περιμένει για μια συγκεκριμένη σειρά μηνυμάτων. Εάν ληφθεί ένα απροσδόκητο μήνυμα ή χαθεί η σύνδεση, ο πελάτης εξέρχεται με κωδικό 1. Εάν ληφθεί το τελευταίο αναμενόμενο μήνυμα, ο πελάτης εξέρχεται με κωδικό 0.
Ο Newman εργάζεται ταυτόχρονα με τον πελάτη. Πολλοί πελάτες ξεκινούν για να ελέγξουν ότι τα μηνύματα παραδίδονται σε όλους όσους τα χρειάζονται.
Για να εκτελέσετε πολλούς πελάτες χρησιμοποιήστε την επιλογή --κλίμακα στη γραμμή εντολών docker-compose.
Πριν εκτελεστεί, η δέσμη ενεργειών Postman περιμένει όλους τους πελάτες να δημιουργήσουν συνδέσεις.
Έχουμε ήδη αντιμετωπίσει το πρόβλημα της αναμονής για σύνδεση. Αλλά υπήρχαν διακομιστές, και εδώ είναι ο πελάτης. Χρειάζεται μια διαφορετική προσέγγιση.
Λύση: ο πελάτης στο κοντέινερ χρησιμοποιεί τον μηχανισμό για να ενημερώσετε το σενάριο στον κεντρικό υπολογιστή σχετικά με την κατάστασή του. Ο πελάτης δημιουργεί ένα αρχείο σε μια συγκεκριμένη διαδρομή, ας πούμε /healthcheck, μόλις δημιουργηθεί η σύνδεση. Το σενάριο HealthCheck στο αρχείο docker μοιάζει με αυτό:
HEALTHCHECK --interval=3s CMD if [ ! -e /healthcheck ]; then false; fiΟμάδα επιθεώρηση λιμενεργατών Εμφανίζει την κανονική κατάσταση, την κατάσταση υγείας και τον κωδικό εξόδου για το κοντέινερ.
Μετά την ολοκλήρωση του Newman, το σενάριο ελέγχει ότι όλα τα κοντέινερ με τον πελάτη έχουν τερματιστεί, με κωδικό 0.
Η Happinnes υπάρχει
Αφού ξεπεράσαμε τις δυσκολίες που περιγράφηκαν παραπάνω, είχαμε ένα σύνολο σταθερών δοκιμών τρεξίματος. Σε δοκιμές, κάθε υπηρεσία λειτουργεί ως ενιαία μονάδα, αλληλεπιδρώντας με τη βάση δεδομένων και το Amazon LocalStack.
Αυτές οι δοκιμές προστατεύουν μια ομάδα 30+ προγραμματιστών από σφάλματα σε μια εφαρμογή με πολύπλοκη αλληλεπίδραση 10+ μικροϋπηρεσιών με συχνές αναπτύξεις.
Πηγή: www.habr.com