Μοcking και ο πόνος του broken test
Σήμερα σκεφτόμουν την απίστευτην παρουσίαση του Robert C Martin.Περί της ευθύνης του κάθε προγραμματιστή. Do no Harm έλεγε ο uncle bob, με τον κώδικα σου με το πως υλοποιείς με το να τεστάρεις. Μην λες αμέσως ναι σε κάθε request του management - σκέψου, ανέλυσε τα υπέρ και τα κατά, μερικές φορές πες όχι όταν κάτι ήταν παράλογο. Σήμερα ήταν μια τέτοια μέρα.
Μέσα σε έναν σχετικά πολύπλοκο κόσμο, τον κόσμο του συστήματος που αναπτύσσουμε μου ζητήθηκε να κάνω μια μικρή αλλαγή - η οποία καταστρατηγεί την λογική συγκεκριμένου module, σπάει την όποια ωραία υλοποίηση του αγαπητού συναδέλφου μου (ο οποίος με διαβάζει κιόλας χαχαη hello vlad!). 5 με 6 γραμμές κώδικα οι οποίες φυτρώνουν κάτι εκεί που δε θα έπρεπε.
Πριν το κάνω, απο την προηγουμενη εβδομάδα είχα νιώσει το do no harm και είχα γράψει ένα email το οποίο εξηγούσε οτι η συγκεκριμένη αλλαγή αν γινόταν με τον γρήγορο και πρόχειρο τρόπο θα είχε α) μικρό κόστος υλοποίησης β) potentially μεγάλο κόστος regression testing γ) μεγάλο κόστος σε maintenability - δηλαδή αν το διαβάσει ένας άσχετος μετά απο μερικούς μήνες δε θα το καταλάβει. Η άλλη αντιπρόταση ήταν να γίνει πιο σωστά - με μεγαλύτερες αλλαγές και χρόνο - αλλά θα ήταν ολοκάθαρη λύση.
Η απάντηση που έλαβα και μάλλον, λαμβάνετε και εσείς αγαπητοί συνάδελφοι ήταν - do it γρήγορα. Do no harm Λοιπόν, και αφού είχα κάνει το χρέος μου σαν επαγγελματίας και είχα εξαντλήσει τα όρια της ευθύνης και δύναμης που έχω προχώρησα. Μισή ώρα δουλειά το hack - επίτηδες το πλασάρω πάντα έτσι για να μπορώ να τονίζω σε έναν non techie αναλυτή οτι αυτό δεν είναι σωστό.
6 γραμμές κώδικα σε ένα μεγάλο module που γενικά δεν το έχουν πειράξει αρκετοί - φέρνει σπασμένα test-s τα οποία με αρκετό μεράκι ο αγαπητός συνάδελφος - έχτισε expectation με expectation. Οπαδός και χρήστης του JMock δεν ήμουν ποτέ - το ομολογώ, βρίσκω το Mockito αρκετά πιο όμορφο και απλό -αν και γενικότερα αρχίζω να πιστεύω μετά από λίγα χρόνια εμπειρία οτι το Mocking σαν τεχνική σε αρκετά πολύπλοκο κώδικα από ένα σημείο και μετά γίνεται εφιάλτης maintenance και χάνεις πολλές ώρες.
Ξεκινάω να διαβάζω και κάπου έχασα τη μπάλα - expectation εδώ και εκεί - μία γραμμή μία κλήση σε κώδικα που γίνεται expected να αλλάξεις και τα γ@μησες όλα - απλά η σειρά σε 2 statement και τέλος. Μετά από βοήθεια αρχίζω να φυτρώνω και εγώ τα extra expectations μου, αφού προσπάθησα να βρώ τον κατάλληλο τρόπο έτσι ώστε όταν τα διαβάσει κάποιος άλλος να καταλάβει. Συνέχισα μέχρι που έπεσα σε σενάρια όπου μερικά chain invocation στον κανονικό κώδικα που έμπλεκα Mocked και non mocked objects δεν μπορούσαν να σπάσου σε απλά expectations (κλήσεις μεθόδων δηλαδή).
Έφαγα αρκετή ώρα και τελικά δε βρήκα την καλή λύση. καθώς γύριζα στο σπίτι σκεφτόμουν αυτό το μικρό if που ήταν η αλλαγή και βρήκα οτι πρέπει να προσθέσω και κάτι άλλο - που σημαίνει και κάποιο άλλο φυτεμένο expectation κάπου απλά να υπάρχει για να δουλέψει.
Εκει θυμήθηκα τον κακόμοιρο στο συνέδριο που τόλμησε να πει στον uncle bob οτι είναι πόνος να κάνεις maintain tests και να προσθέσω ιδιαίτερα όταν δεν τα έχεις γράψει εσύ και έφαγε την κατσάδα του αιώνα.
Απο τη μικρή μου εμπειρία στην Ελλάδα σχεδόν πάντα με πάντα θα σου πουν do it the quick and dirty way -(ίσως και παντού τελικά)- που ακόμα και αν έχεις κάτσει και γράψει ένα καλό test πιο πριν θα πρέπει να το βιάζεις δεξιά και αριστερά για να το κάνεις να συμπεριφέρεται σωστά με την αλλαγμένη σου υλοποίηση.
Ελπιζω να μην αργήσουν αρκετά τα πράγματα και με την έλευση του j2ee6 spec και του standalone container αρκετό mocking να πάρει πόδι. Ωραία τεχνική δε λέω αλλά όταν το πράγμα μεγαλώνει - σου κοστίζει 3 φορές τον χρόνο να κάνεις αλλαγή στο test παρά στο σύστημα. Όλα είναι θέμα επιλογών υποθέτω. Απο την άλλη μάλλον, ακόμα δεν έχουμε βρει και τους πιο ωραίους τρόπους να τεστάρουμε- έτσι ώστε να μην το θεωρούμε μαρτύριο αλλά αντίστοιχα enjoyable όπως ο κώδικας.
many many expectations .allowing :P