SaaS
Πρώτα το τεστ, μετά ο κώδικας σε μια πλατφόρμα SaaS
Στην ανάπτυξη με δοκιμές (TDD) γράφεται πρώτα ένα τεστ που αποτυγχάνει, μετά ο κώδικας που το περνά και τέλος η βελτίωση του κώδικα. Έτσι κάθε λειτουργία μιας πλατφόρμας SaaS έχει από την αρχή τον έλεγχό της. Οι περισσότερες δοκιμές είναι μικρές και γρήγορες, ενώ λίγες ελέγχουν το σύνολο στον browser.
Μια πλατφόρμα SaaS αλλάζει συνεχώς: νέες λειτουργίες, νέοι ρόλοι, νέοι πελάτες. Χωρίς αυτόματους ελέγχους, κάθε αλλαγή αφήνει την ερώτηση αν χάλασε κάτι που δούλευε. Εμείς γράφουμε για κάθε λειτουργία πρώτα το τεστ και μετά τον κώδικα. Έτσι ο έλεγχος δεν είναι τελευταίο βήμα που μπορεί να παραλειφθεί, αλλά το σημείο από το οποίο ξεκινά η δουλειά.
Τι είναι η ανάπτυξη με δοκιμές;
Η ανάπτυξη με δοκιμές, γνωστή ως TDD (test-driven development), είναι μια μέθοδος όπου το τεστ γράφεται πριν από τον κώδικα που ελέγχει. Ο Martin Fowler την περιγράφει με τρία βήματα. Γράφεις ένα τεστ για την επόμενη λειτουργία, γράφεις τον κώδικα μέχρι να περάσει, και βελτιώνεις τον νέο και τον παλιό κώδικα ώστε να είναι καλά δομημένος.
Τα τρία βήματα επαναλαμβάνονται σε κύκλο, γνωστό ως red-green-refactor: το τεστ αποτυγχάνει (red), περνά (green) και ο κώδικας τακτοποιείται (refactor). Ο Fowler προσθέτει ότι πριν ξεκινήσει ο κύκλος γράφεται μια λίστα με τις περιπτώσεις που πρέπει να ελεγχθούν, και κάθε φορά δουλεύεται μία. Η μέθοδος δεν αφορά ειδικά τις πλατφόρμες, όμως σε αυτές αποδίδει περισσότερο, επειδή ζουν πολλά χρόνια και αλλάζουν συνεχώς.
Γιατί γράφεται το τεστ πρώτο;
Το τεστ γράφεται πρώτο γιατί αποδεικνύει ότι μπορεί να αποτύχει. Ένα τεστ που γράφεται μετά τον κώδικα συχνά περνά από την πρώτη φορά, και δεν ξέρει κανείς αν θα έπιανε ποτέ ένα λάθος. Όταν το βλέπουμε να αποτυγχάνει πρώτα, ξέρουμε ότι ελέγχει πράγματι κάτι.
Υπάρχει και δεύτερο όφελος. Για να γραφτεί το τεστ, η λειτουργία πρέπει να περιγραφεί ακριβώς: τι δέχεται, τι επιστρέφει, τι γίνεται όταν κάτι πάει στραβά. Αυτό δείχνει νωρίς τι λείπει από τις απαιτήσεις, όταν η διόρθωση κοστίζει μια ερώτηση και όχι μια αναδιάρθρωση. Γι' αυτό η μέθοδος ταιριάζει με την ανάλυση απαιτήσεων πριν από τον κώδικα.
Ποιες δοκιμές χρειάζονται και πόσες;
Χρειάζονται πολλές μικρές δοκιμές και λίγες μεγάλες. Αυτή είναι η ιδέα της πυραμίδας δοκιμών (test pyramid), όπως τη διατυπώνει ο Fowler: πολύ περισσότερες δοκιμές χαμηλού επιπέδου από δοκιμές που περνούν μέσα από την οθόνη. Στη μέση βρίσκεται ένα επίπεδο δοκιμών που ελέγχουν την εφαρμογή μέσα από το επίπεδο υπηρεσιών της.
Επίπεδο | Τι ελέγχει | Πόσες |
|---|---|---|
Μικρές δοκιμές | Έναν κανόνα ή έναν υπολογισμό, μεμονωμένα | Οι περισσότερες |
Δοκιμές υπηρεσιών | Μια λειτουργία μέσα από το επίπεδο υπηρεσιών της εφαρμογής | Μέτριος αριθμός |
Δοκιμές οθόνης | Μια πλήρη διαδρομή χρήστη στον browser | Οι λιγότερες |
Ο Fowler εξηγεί γιατί οι δοκιμές οθόνης πρέπει να είναι λίγες: είναι ευαίσθητες, ακριβές στη συγγραφή και αργές στην εκτέλεση. Σημειώνει όμως και μια εξαίρεση. Αν οι δοκιμές υψηλού επιπέδου είναι γρήγορες, αξιόπιστες και φτηνές στην αλλαγή, τότε οι χαμηλού επιπέδου δεν χρειάζονται. Στην πράξη λίγες δοκιμές αναπαράγουν την πραγματική χρήση, και οι μικρές κάνουν το μεγαλύτερο μέρος της δουλειάς.
Πώς δουλεύουμε σε μια πλατφόρμα;
Ακολουθούμε την ίδια σειρά σε κάθε λειτουργία. Η σειρά είναι σύντομη και τηρείται πάντα:
Η απαίτηση γράφεται και εγκρίνεται. Κάθε λειτουργία προέρχεται από τις γραπτές απαιτήσεις του πρώτου σταδίου.
Γράφεται το τεστ και αποτυγχάνει. Ελέγχουμε ότι αποτυγχάνει για τον σωστό λόγο.
Γράφεται ο κώδικας μέχρι να περάσει. Δεν γράφεται τίποτα που δεν ζητά κάποιο τεστ.
Ο κώδικας τακτοποιείται. Μετά από κάθε αλλαγή τρέχουν ξανά οι δοκιμές.
Η λειτουργία ελέγχεται στον browser. Την ανοίγουμε σαν χρήστης και τη συγκρίνουμε με το εγκεκριμένο σχέδιο.
Κάθε στάδιο προχωρά μόνο όταν περάσουν όλοι οι έλεγχοι. Το εργαλείο μας Planner εφαρμόζει αυτή τη σειρά όταν φτιάχνει μια εφαρμογή από γραπτή προδιαγραφή, και το περιγράφουμε στο case study του Planner. Σημαντικό είναι ότι οι δοκιμές δεν χαλαρώνουν για να περάσουν: αν ένας έλεγχος αποτύχει, διορθώνεται ο κώδικας.
Πώς μοιάζει ένα τεστ στην πράξη;
Ένα τεστ είναι μια πρόταση από τις απαιτήσεις, γραμμένη έτσι ώστε να την ελέγχει ένα πρόγραμμα. Αν ο πίνακας δικαιωμάτων λέει ότι ένας χειριστής δεν εγκρίνει αιτήματα, το τεστ ξεκινά ως χειριστής, προσπαθεί να εγκρίνει ένα αίτημα και περιμένει άρνηση. Πριν γραφτεί ο κώδικας το τεστ αποτυγχάνει, γιατί η άρνηση δεν υπάρχει ακόμη.
Μετά γράφεται ο κώδικας που αρνείται την έγκριση, και το τεστ περνά. Αν κάποιος αλλάξει αργότερα τον κανόνα κατά λάθος, το ίδιο τεστ αποτυγχάνει αμέσως, πριν η αλλαγή φτάσει σε χρήστες. Έτσι οι απαιτήσεις που εγκρίνατε μένουν ενεργές και μετά την παράδοση, και όχι μόνο στο χαρτί.
Τι γίνεται όταν βρεθεί σφάλμα;
Όταν βρεθεί σφάλμα, γράφεται πρώτα ένα τεστ που το αναπαράγει. Το τεστ αποτυγχάνει πριν από τη διόρθωση και περνά μετά. Έτσι το ίδιο λάθος δεν μπορεί να επανέλθει χωρίς να το πιάσει κάποιος έλεγχος, και κάθε διόρθωση αφήνει πίσω της μόνιμη προστασία.
Αυτό ισχύει και για όσα βρίσκει η ομάδα των agents που εξετάζει το ολοκληρωμένο έργο για σφάλματα, χρηστικότητα και ασφάλεια. Κάθε επιβεβαιωμένο εύρημα διορθώνεται με τον ίδιο τρόπο. Τη διαδικασία την εξηγούμε στο case study των agents ποιότητας και ασφάλειας. Ένα καλό παράδειγμα είναι η ασφάλεια των δικαιωμάτων, που περιγράφουμε στο άρθρο για τους ρόλους και τα δικαιώματα σε ένα SaaS.
Συχνές ερωτήσεις: Πρώτα το τεστ, μετά ο κώδικας σε μια πλατφόρμα SaaS
Κάνει το TDD το έργο πιο αργό;
Στην αρχή κάθε λειτουργία θέλει λίγο περισσότερο χρόνο, γιατί γράφεται και ο έλεγχός της. Αυτός ο χρόνος γλιτώνεται αργότερα, όταν οι αλλαγές ελέγχονται αυτόματα και όχι με το χέρι. Σε μια πλατφόρμα που θα αλλάζει για χρόνια, το κέρδος είναι σαφές.
Χρειάζονται δοκιμές σε κάθε πλατφόρμα;
Όσο πιο πολύπλοκη είναι μια πλατφόρμα και όσο περισσότερα χρόνια λειτουργεί, τόσο περισσότερο τις χρειάζεται. Σε ένα μικρό εσωτερικό εργαλείο αρκεί λιγότερο πυκνός έλεγχος. Το πόσο ακριβώς συμφωνείται στις απαιτήσεις και γράφεται στο αντικείμενο έργου.
Αντικαθιστούν οι αυτόματες δοκιμές τον έλεγχο από άνθρωπο;
Όχι. Οι αυτόματες δοκιμές πιάνουν τα λάθη που μπορούν να περιγραφούν από πριν. Για αυτό ελέγχουμε και στον browser, σαν χρήστες, και δοκιμάζουμε το αποτέλεσμα σε πραγματικά σενάρια από την καθημερινή σας δουλειά. Τα δύο συμπληρώνουν το ένα το άλλο.
Τι σημαίνει ότι πέρασαν όλοι οι έλεγχοι;
Σημαίνει ότι κανένα τεστ δεν αποτυγχάνει και ότι η λειτουργία έχει δοκιμαστεί και στον browser. Μόνο τότε προχωράμε στο επόμενο βήμα, ώστε ένα λάθος να μη μεταφέρεται στη συνέχεια. Τι ακριβώς περιλαμβάνει η παράδοση γράφεται στο αντικείμενο έργου που εγκρίνετε στην αρχή.
Θέλετε μια πλατφόρμα που ελέγχεται από την αρχή;
Αν σχεδιάζετε προϊόν SaaS ή εσωτερική πλατφόρμα και θέλετε να ξέρετε πώς θα ελέγχεται κάθε λειτουργία, περιγράψτε το έργο σας στο αίτημα έργου. Θα συζητήσουμε μαζί τις δοκιμές στο στάδιο των απαιτήσεων. Δείτε και τη σελίδα για τις πλατφόρμες SaaS.