Regression testing των Boomi integrations πριν από το deploy

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

Γι’ αυτό υπάρχει το regression testing: ξαναελέγχετε όλα όσα δούλευαν, κάθε φορά που κάτι αλλάζει. Σε αυτό το άρθρο εξηγούμε το pattern γενικά, και μετά το φτιάχνουμε για Boomi processes.

Γιατί ο χειροκίνητος επανέλεγχος δεν κλιμακώνεται

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

Η απάντηση είναι ένα σύνολο tests που:

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

Το pattern: test harness

Ένα test harness είναι μια ξεχωριστή ροή με μοναδική δουλειά να τρέχει περιπτώσεις ελέγχου πάνω στη λογική που θέλετε να προστατέψετε.

Για κάθε περίπτωση:
  έγγραφο εισόδου    ──► λογική υπό έλεγχο ──► πραγματική έξοδος
  αναμενόμενη έξοδος ──────────────────────────► σύγκριση ──► pass / fail
Σύνοψη: N επιτυχίες, M αποτυχίες ──► συνολική κατάσταση (success / error)

Τρεις σχεδιαστικές αποφάσεις το κάνουν να δουλεύει:

Ελέγχετε τη λογική, όχι τους connectors. Το harness καλεί απευθείας τη λογική mapping, επικύρωσης και εμπλουτισμού με αποθηκευμένες εισόδους. Δεν διαβάζει από το πραγματικό e-shop ούτε γράφει στο πραγματικό ERP. Έτσι μένει γρήγορο, επαναλήψιμο και χωρίς παρενέργειες. Οι connectors καλύπτονται από λίγα end-to-end tests.
Κανονικοποίηση πριν από τη σύγκριση. Οι έξοδοι συχνά περιέχουν τιμές που αλλάζουν σε κάθε εκτέλεση: timestamps, IDs που δημιουργούνται, execution IDs. Αφαιρέστε ή σταθεροποιήστε τες πριν από τη σύγκριση, αλλιώς θα αποτυγχάνει κάθε test.
Η αποτυχία να φαίνεται σε μηχανές. Το harness πρέπει να τελειώνει σε σαφή κατάσταση αποτυχίας όταν αποτύχει οποιαδήποτε περίπτωση, ώστε ένα pipeline να μπορεί να σταματήσει το deploy.

Υλοποίηση στο Boomi

Δεν υπάρχει ένα ενσωματωμένο κουμπί «regression suite» για τα Boomi processes, οπότε αυτό είναι ένα pattern που φτιάχνετε από τυπικά components. Τα κομμάτια παρακάτω είναι σκόπιμα απλά· προσαρμόστε τα στις δικές σας συμβάσεις.

Βήμα 1: Κάντε τη λογική «καλέσιμη»

Αν ακολουθήσατε το Testing των Boomi processes κατά την ανάπτυξη, η επιχειρηματική λογική ζει ήδη σε ένα subprocess που τελειώνει με shape Return Documents:

Order sync (σε deploy):   connector e-shop ──► Process Call "Order logic" ──► connector ERP
Order logic (subprocess): Map ──► επικυρώσεις ──► lookups ──► Return Documents

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

Βήμα 2: Αποθήκευση των περιπτώσεων

Για κάθε περίπτωση κρατάτε δύο αρχεία με αντίστοιχα ονόματα, για παράδειγμα:

regression/order-logic/
  001-standard-order.input.json
  001-standard-order.expected.xml
  002-credit-note.input.json
  002-credit-note.expected.xml
  003-greek-long-address.input.json
  003-greek-long-address.expected.xml
  004-unknown-payment.input.json
  004-unknown-payment.expected.xml   (αναμένεται: απόρριψη, με αυτό το μήνυμα σφάλματος)

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

Το πώς διαβάζει το harness τα αρχεία εξαρτάται από το runtime. Σε τοπικό Atom ή Molecule, ο connector Disk μπορεί να τα διαβάζει από φάκελο που το pipeline κρατά συγχρονισμένο με το repository. Σε cloud runtime χωρίς κοινόχρηστο φάκελο, μπορείτε να ενσωματώσετε τις περιπτώσεις σε shapes Message μέσα στο harness, ή να τις φέρνετε από repository ή υπηρεσία αποθήκευσης με μια κλήση HTTP.

Βήμα 3: Το harness process

Μια απλή δομή:

Διαβάστε τις εισόδους (Disk Get ή shapes Message), κρατώντας το όνομα της περίπτωσης σε ένα dynamic document property.
Διαβάστε την αντίστοιχη αναμενόμενη έξοδο για κάθε περίπτωση και κρατήστε τη σε άλλο dynamic document property, ή φορτώστε τα αναμενόμενα αρχεία σε document cache με κλειδί το όνομα της περίπτωσης.
Process Call προς το subprocess της λογικής, το ίδιο component που χρησιμοποιεί το πραγματικό process.
Κανονικοποιήστε την πραγματική έξοδο: αφαιρέστε timestamps και IDs που δημιουργούνται, για παράδειγμα με ένα μικρό map ή ένα βήμα script.
Συγκρίνετε πραγματική και αναμενόμενη έξοδο. Για ακριβή σύγκριση, ένα shape Data Process με σύντομο custom script είναι συνήθως η πιο απλή λύση· μπορεί να βγάλει και ευανάγνωστη διαφορά. Για λίγα βασικά πεδία, αρκεί ένα shape Decision που συγκρίνει properties.
Καταγράψτε το αποτέλεσμα ανά περίπτωση με ένα shape Notify (PASS 002-credit-note ή FAIL 002-credit-note: Amount expected -24.80, got 24.80).
Κάντε την εκτέλεση να αποτύχει αν απέτυχε οποιαδήποτε περίπτωση: οδηγήστε τις αποτυχίες σε shape Exception αφού επεξεργαστούν όλες οι περιπτώσεις, ώστε η εκτέλεση να τελειώσει με κατάσταση σφάλματος.

Το βήμα 5 είναι αυτό που διαφέρει περισσότερο από ομάδα σε ομάδα. Κρατήστε τη σύγκριση αυστηρή για τα πεδία που μετράνε (ποσά, κωδικοί, ποσότητες, ημερομηνίες) και αποφασίστε ρητά τι αγνοείτε.

Βήμα 4: Εκτέλεση σε test περιβάλλον

Κάντε deploy το harness μόνο στο test περιβάλλον, ποτέ στην παραγωγή. Πρέπει να γίνεται deploy μαζί με την έκδοση του subprocess λογικής που θέλετε να ελέγξετε, με τα ίδια packaged components που σκοπεύετε να προωθήσετε.

Όσο το φτιάχνετε, τρέξτε το από τον editor σε Test mode. Όταν δουλεύει, κάντε deploy και τρέξτε το ως κανονική εκτέλεση, ώστε να ξεκινά και απομακρυσμένα.

Βήμα 5: Εκτέλεση από pipeline

Το Boomi Platform API (παλαιότερα AtomSphere API) επιτρέπει σε εξωτερικά εργαλεία να διαχειρίζονται deployments και να ξεκινούν processes. Ένα βήμα του pipeline μπορεί να:

Κάνει deploy το νέο package στο test περιβάλλον.
Ξεκινήσει το harness process στο test runtime.
Περιμένει να τελειώσει η εκτέλεση και διαβάσει την κατάστασή της.
Σταματήσει το pipeline αν η κατάσταση είναι σφάλμα· αλλιώς συνεχίζει προς την παραγωγή.

Η εκκίνηση ενός process γίνεται με ένα execution request. Σε γενικές γραμμές μοιάζει με το παρακάτω· ελέγξτε το τρέχον API reference για το ακριβές endpoint, το payload και τις επιλογές ταυτοποίησης του λογαριασμού σας:

# Μόνο σκιαγράφηση: επιβεβαιώστε τις λεπτομέρειες στο API reference του Boomi Platform API
curl -s -u "BOOMI_TOKEN.ci-user@example.gr:$BOOMI_API_TOKEN" \
  -H "Content-Type: application/json" -H "Accept: application/json" \
  -X POST "https://api.boomi.com/api/rest/v1/$ACCOUNT_ID/ExecutionRequest" \
  -d '{
        "@type": "ExecutionRequest",
        "atomId": "'"$TEST_ATOM_ID"'",
        "processId": "'"$HARNESS_PROCESS_ID"'"
      }'

Η απάντηση ταυτοποιεί το αίτημα. Το pipeline ελέγχει μετά περιοδικά το execution record μέχρι να φτάσει σε τελική κατάσταση, και θεωρεί την κατάσταση σφάλματος αποτυχημένο test. Χρησιμοποιήστε ξεχωριστό API χρήστη με μόνο τα δικαιώματα που χρειάζεται το pipeline, και φυλάξτε το token στο secret store του pipeline, ποτέ μέσα στο script.

Το πώς ταιριάζει αυτό με το packaging και την προώθηση ανάμεσα σε περιβάλλοντα το καλύπτουμε στο Packaged deployments στο Boomi.

Πριν βγείτε σε παραγωγή

Ξεκινήστε μικρά. Δέκα καλές περιπτώσεις που καλύπτουν τους βασικούς τύπους εγγράφων και τις γνωστές οριακές περιπτώσεις αξίζουν περισσότερο από εκατό αντίγραφα της ίδιας παραγγελίας.
Ελέγχετε τις αναμενόμενες εξόδους. Όταν μια αλλαγή είναι σκόπιμη, ενημερώστε τα αναμενόμενα αρχεία στην ίδια αλλαγή και ζητήστε από κάποιον να ελέγξει τη διαφορά.
Ποτέ το harness προς συστήματα παραγωγής. Ελέγχει λογική. Αν ποτέ χρειαστεί connector, χρησιμοποιήστε test instances ή mocks.
Προσέξτε τον χρόνο εκτέλεσης. Αν το suite αργεί, θα θέλουν να το παρακάμπτουν. Χωρίστε το ανά ροή και τρέχετε ό,τι άλλαξε.
Masking στα test data. Περιπτώσεις από την παραγωγή δεν πρέπει να έχουν πραγματικά προσωπικά δεδομένα.

Συνοψίζοντας

Το regression testing προστατεύει όλα όσα δεν θέλατε να αλλάξετε. Για τα integrations, το pattern είναι ένα harness που δίνει σταθερές εισόδους στη λογική, συγκρίνει τα αποτελέσματα με αναμενόμενες εξόδους και αποτυγχάνει καθαρά. Στο Boomi το φτιάχνετε από τυπικά κομμάτια: ένα «καλέσιμο» subprocess λογικής, αποθηκευμένες περιπτώσεις, ένα harness process, ένα test περιβάλλον και το Platform API για εκτέλεση από pipeline. Για τη συνολική εικόνα, δείτε τον οδηγό για testing integrations.