Testing integrations: πρακτικός οδηγός

Τα περισσότερα bugs στα integrations εντοπίζονται με τον ίδιο τρόπο: ένας πελάτης τηλεφωνεί γιατί η παραγγελία του δεν έφτασε ποτέ, ή το λογιστήριο βλέπει ότι λείπουν τα τιμολόγια της περασμένης Τρίτης. Το integration «δούλευε» στις δοκιμές, με μία καθαρή παραγγελία-δείγμα, ένα ήσυχο απόγευμα. Απλώς δεν δούλεψε με πραγματικά δεδομένα, πραγματικούς όγκους ή ένα σύστημα συνεργάτη που έπεσε για είκοσι λεπτά.

Το σωστό testing integrations είναι πιο δύσκολο από το testing μιας κανονικής εφαρμογής, αλλά δεν είναι μυστήριο. Ο οδηγός εξηγεί γιατί είναι δύσκολο, ποια επίπεδα testing μετράνε, πώς χειρίζεστε test data και εξωτερικά συστήματα, και τι αξίζει να αυτοματοποιηθεί.

Γιατί τα integrations ελέγχονται δύσκολα

Δεν σας ανήκουν τα συστήματα στις δύο άκρες. Το ERP, το e-shop και το API της courier είναι κάποιου άλλου, μπορεί να μην έχουν test instance, και μπορεί να χρεώνουν ανά κλήση ή να στέλνουν πραγματικά emails.
Η συμπεριφορά εξαρτάται από τα δεδομένα. Η ίδια ροή δουλεύει για 99 παραγγελίες και αποτυγχάνει σε αυτή με έναν ελληνικό χαρακτήρα σε περίεργο σημείο, μια γραμμή μηδενικής τιμής ή έναν πελάτη που δεν υπάρχει ακόμη.
Ο χρόνος και η κατάσταση μετράνε. Οι incremental συγχρονισμοί εξαρτώνται από το «τι άλλαξε από την τελευταία εκτέλεση». Τα retries εξαρτώνται από το τι έγινε πριν. Ένα test που περνά μία φορά μπορεί να αποτύχει τη δεύτερη.
Οι αποτυχίες είναι μερικές. Φτάνει μισή παραγγελία· το απόθεμα ενημερώνεται αλλά το τιμολόγιο όχι. Αυτά είναι τα πιο δύσκολα bugs και τα λιγότερο ελεγμένα.
Τα περιβάλλοντα αποκλίνουν. Test και παραγωγή έχουν διαφορετικούς κωδικούς, χρήστες και όγκους.

Τα επίπεδα testing

Η γνωστή «πυραμίδα» του testing ισχύει και εδώ, με ειδικό νόημα για τα integrations σε κάθε επίπεδο.

Unit tests: η λογική απομονωμένη

Ελέγχετε ένα κομμάτι λογικής με σταθερή είσοδο και αναμενόμενη έξοδο, χωρίς κανένα εξωτερικό σύστημα: ένα mapping, έναν υπολογισμό, έναν κανόνα επικύρωσης. Είναι γρήγορα, φθηνά και πρέπει να είναι ο κύριος όγκος των tests σας. Ειδικά τα mappings αξίζουν unit tests με πραγματικά (ανωνυμοποιημένα) δείγματα, όπως περιγράφουμε στον οδηγό για data mapping.

Για να γίνεται unit testing, σχεδιάστε γι’ αυτό: κρατήστε τη λογική (mapping, επικύρωση, εμπλουτισμός) χωριστά από τη συνδεσιμότητα (ανάγνωση από το e-shop, εγγραφή στο ERP). Λογική που δεν τρέχει χωρίς το ERP είναι λογική που δεν ελέγχεται με unit tests.

Component tests: μία ροή, με αντικαταστάτες

Ελέγχετε ολόκληρη ροή, με τα εξωτερικά συστήματα να αντικαθίστανται από mocks ή stubs που συμπεριφέρονται προβλέψιμα. Εδώ ελέγχετε τους δρόμους που δύσκολα προκαλούνται στην πράξη: το ERP επιστρέφει σφάλμα, το API κάνει timeout, ο συνεργάτης στέλνει διπλότυπο.

End-to-end tests: η πραγματική αλυσίδα

Ελέγχετε όλη την αλυσίδα σε μη-παραγωγικό περιβάλλον με τα test instances των πραγματικών συστημάτων: βάζετε παραγγελία στο test e-shop και την ελέγχετε στο test ERP. Είναι αργά, εύθραυστα και ακριβά, οπότε κρατήστε τα λίγα και επικεντρωμένα στα σημαντικότερα επιχειρηματικά σενάρια.

Επίπεδο	Τι τρέχει	Ταχύτητα	Πόσα
Unit	Ένα map ή ένας κανόνας	Δευτερόλεπτα	Πολλά
Component	Μία ροή, εξωτερικά συστήματα ως mocks	Λεπτά	Ένα σετ ανά ροή
End-to-end	Πραγματικά test instances	Αργά	Λίγα βασικά σενάρια

Test data και masking

Τα καλά test data είναι ο σημαντικότερος παράγοντας για την ποιότητα των tests. Φτιάξτε ένα σύνολο test data ανά interface που περιλαμβάνει:

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

Τα δεδομένα παραγωγής είναι η καλύτερη πηγή ρεαλιστικών περιπτώσεων, αλλά περιέχουν προσωπικά δεδομένα. Με τον GDPR, η αντιγραφή ονομάτων, emails, τηλεφώνων και ΑΦΜ πελατών σε test περιβάλλον χρειάζεται λόγο και προστασία. Η συνηθισμένη απάντηση είναι το masking: αντικαθιστάτε τα προσωπικά πεδία με ρεαλιστικές ψεύτικες τιμές, διατηρώντας δομή, μήκη και character sets. Ένας «masked» πελάτης C-1042 πρέπει να έχει ακόμη ελληνικό όνομα ίδιου μήκους, όχι XXXXX.

Κρατήστε τα test data σε version control δίπλα στο integration, και αντιμετωπίστε τις αλλαγές τους όπως τις αλλαγές κώδικα.

Mocking εξωτερικών συστημάτων

Ένα mock είναι μια ψεύτικη εκδοχή ενός εξωτερικού συστήματος που επιστρέφει ό,τι του πείτε. Με mocks:

ελέγχετε χωρίς test instance του πραγματικού συστήματος,
ελέγχετε απαντήσεις σφάλματος (500, timeouts, λάθος JSON) όποτε θέλετε,
ξανατρέχετε τα tests με τα ίδια αποτελέσματα.

Τα mocks μπορεί να είναι αυτόνομοι HTTP servers που μιμούνται ένα API, ή απλοί αντικαταστάτες μέσα στην πλατφόρμα integration, όπως η αντικατάσταση μιας κλήσης connector με σταθερή απάντηση σε μια test εκδοχή της ροής. Κρατήστε τα mocks τίμια: να βασίζονται σε πραγματικές καταγεγραμμένες απαντήσεις και να ενημερώνονται όταν αλλάζει το πραγματικό σύστημα. Ένα mock πιο «ανεκτικό» από το πραγματικό σύστημα δίνει ψεύτικη σιγουριά.

Contract testing

Όταν δύο ομάδες ή δύο εταιρείες φτιάχνουν τις δύο πλευρές ενός interface, το contract testing ελέγχει ότι συμφωνούν στη μορφή χωρίς να τις τρέξει μαζί. Ο consumer γράφει τι περιμένει (πεδία, τύπους, status codes), και ο provider τρέχει ένα test που ελέγχει ότι το παρέχει ακόμη. Πιάνει το «μετονομάσαμε ένα πεδίο» πριν από το deploy, όχι μετά.

Τα εξειδικευμένα εργαλεία contract testing είναι πιο χρήσιμα όταν και οι δύο πλευρές αναπτύσσονται ενεργά. Για ένα σταθερό API τρίτου, αρκεί μια απλούστερη εκδοχή: κρατήστε το schema του API (OpenAPI, XSD) σε version control, ελέγχετε τις πραγματικές απαντήσεις απέναντί του στα tests σας, και φροντίστε να ενημερώνεστε όταν αλλάζει.

Regression suites

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

Το suite δουλεύει μόνο αν τρέχει αυτόματα και αν η αποτυχία του μπλοκάρει το deploy. Ένα suite που κάποιος πρέπει να θυμηθεί να τρέξει θα παραλειφθεί την πιο πιεσμένη μέρα. Ο οδηγός για DevOps στα integrations δείχνει πώς εντάσσεται σε ένα deployment pipeline.

Testing σε μη-παραγωγικά περιβάλλοντα

Έχετε τουλάχιστον ένα test περιβάλλον που αντιγράφει τις ρυθμίσεις της παραγωγής: ίδια processes, ίδιες εκδόσεις, test διαπιστευτήρια και test endpoints.
Συνδέστε το σε test instances, ποτέ σε συστήματα παραγωγής «μόνο για ένα γρήγορο test».
Κρατήστε τις ρυθμίσεις χωριστά από τον κώδικα, ώστε το ίδιο ελεγμένο package να πάει στην παραγωγή αλλάζοντας μόνο τις ρυθμίσεις.
Προσοχή στις παρενέργειες: emails σε πραγματικούς πελάτες, πραγματικά SMS, πραγματικές κρατήσεις courier, πραγματικά ηλεκτρονικά τιμολόγια. Απενεργοποιήστε ή ανακατευθύνετέ τα στο test.

Τι να αυτοματοποιήσετε

Αυτοματοποιήστε πρώτα ό,τι είναι φθηνό να τρέξει και ακριβό να το χάσετε:

Tests mapping και επικύρωσης με δείγματα δεδομένων.
Component tests για τους δρόμους σφάλματος (προορισμός εκτός λειτουργίας, μη έγκυρα δεδομένα, διπλότυπα).
Το regression suite, πριν από κάθε deploy.

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

Συνηθισμένα λάθη

Test μόνο του happy path. Τα περισσότερα περιστατικά παραγωγής έρχονται από τους δρόμους σφάλματος και τα ασυνήθιστα δεδομένα.
Ένα δείγμα εγγράφου. Μία παραγγελία αποδεικνύει ότι το mapping δουλεύει για μία παραγγελία.
Testing πάνω στην παραγωγή. Η «μία δοκιμαστική παραγγελία» καταλήγει στο πραγματικό ERP και στη δήλωση ΦΠΑ.
Χωρίς αναμενόμενη έξοδο. Το «έτρεξε χωρίς σφάλματα» δεν είναι αποτέλεσμα test. Συγκρίνετε με αυτό που έπρεπε να βγει.
Tests που δεν τρέχει κανείς. Αν δεν είναι αυτόματα και δεν μπλοκάρουν, θα παραλείπονται.

Πώς να συγκρίνετε εργαλεία

Τι χρειάζεται να ελέγξετε; APIs που εκθέτετε, APIs που καλείτε, ροές αρχείων και EDI, ή ροές μέσα σε πλατφόρμα integration.
Κάνει mock σε ό,τι εξαρτάστε; Τα HTTP APIs είναι εύκολα· SOAP, SFTP και βάσεις δεδομένων λιγότερο.
Τρέχει χωρίς επίβλεψη σε pipeline; Command-line runners και αποτελέσματα που διαβάζονται από μηχανή μετράνε περισσότερο από ένα ωραίο UI.
Ποιος γράφει τα tests; Developers, testers ή ειδικοί integration που προτιμούν γραφικό εργαλείο.
Ταιριάζει στην πλατφόρμα σας; Το testing της ίδιας της πλατφόρμας βλέπει μέσα στη ροή· τα εξωτερικά εργαλεία βλέπουν μόνο εισόδους και εξόδους. Οι περισσότερες ομάδες χρειάζονται και τα δύο.

Τα εργαλεία της αγοράς

Με αλφαβητική σειρά.

Boomi Test mode. Ενσωματωμένο στον editor των processes του Boomi: τρέχει ένα process σε test runtime και σας αφήνει να δείτε τα έγγραφα σε κάθε shape. Πολύ καλό για ανάπτυξη και debugging ροών. Για αυτοματοποιημένο regression testing το συνδυάζετε με test-harness processes και το Boomi Platform API.
MuleSoft MUnit. Το framework testing για τις ροές του MuleSoft Anypoint, με mocking connectors και assertions στα αποτελέσματα. Οι ομάδες MuleSoft το χρησιμοποιούν για αυτοματοποιημένα unit και component tests μέσα στο build τους.
Pact. Το πιο γνωστό εργαλείο για consumer-driven contract testing, με βιβλιοθήκες για πολλές γλώσσες και broker για τον διαμοιρασμό των contracts. Πιο χρήσιμο όταν και τις δύο πλευρές ενός API τις φτιάχνουν ομάδες που μπορούν να προσθέσουν tests στον κώδικά τους.
Postman. Δημοφιλής API client που εξελίχθηκε σε πλατφόρμα testing: collections με κλήσεις και scripted assertions, environments, mock servers και command-line runner (Newman / Postman CLI) για pipelines. Εύκολο ξεκίνημα για REST APIs.
SoapUI / ReadyAPI. Το SoapUI είναι το παλιό, καθιερωμένο open-source εργαλείο για testing SOAP και REST· το ReadyAPI είναι η εμπορική σουίτα της SmartBear που προσθέτει data-driven testing, virtualisation και αναφορές. Δυνατό εκεί που κυριαρχούν SOAP και XML.
WireMock. Open-source HTTP mock server: καταγράφει πραγματικές απαντήσεις, τις αναπαράγει και προσομοιώνει σφάλματα και καθυστερήσεις. Χρησιμοποιείται ευρέως στη θέση εξωτερικών APIs σε component tests.

Τα εργαλεία αυτά συμπληρώνουν το ένα το άλλο περισσότερο απ’ ό,τι ανταγωνίζονται. Ένα τυπικό setup χρησιμοποιεί το testing της πλατφόρμας για τη λογική των ροών, ένα εργαλείο API για τα APIs που εκθέτετε και έναν mock server για τα συστήματα που καλείτε.

Επόμενα βήματα

Δύο πρακτικά άρθρα δείχνουν αυτές τις ιδέες στο Boomi:

Testing των Boomi processes κατά την ανάπτυξη: Test mode, δείγματα δεδομένων, έλεγχος εγγράφων ανά shape και testing των δρόμων σφάλματος.
Regression testing των Boomi integrations πριν από το deploy: ένα pattern test-harness και η εκτέλεσή του από pipeline.