Επίπεδο εισαγωγής διαδικτυακής δοκιμής java. Δοκιμή προγράμματος, JUnit. Προαπαιτούμενα Java Test

Πιστεύω ότι η ανάπτυξη λογισμικού είναι κάτι περισσότερο από δουλειά. Βλέπω τον εαυτό μου ως έναν τεχνίτη που προσπαθεί να γίνεται καλύτερος κάθε μέρα. Ο πιο «εύκολος» τρόπος για να το κάνετε αυτό είναι να βρείτε μερικά καλά εργαλεία και να απαντήσετε στις ακόλουθες ερωτήσεις:

• Πότε πρέπει να χρησιμοποιήσω το Tool X;
• Πώς πρέπει να χρησιμοποιήσω το εργαλείο Χ;

Οι αυτοματοποιημένες δοκιμές είναι ένα πολύ σημαντικό μέρος της ανάπτυξης λογισμικού, αλλά υπάρχουν λίγες αναρτήσεις στα ιστολόγια προγραμματιστών σχετικά με τα εργαλεία που χρησιμοποιούνται. Αυτό το ίδιο άρθρο θα σας επιτρέψει να δείτε την «εργαλειοθήκη» μου. Θα καλύψω 12 βιβλιοθήκες και πλαίσια που χρησιμοποιώ για τη σύνταξη δοκιμών ενότητας και ολοκλήρωσης και θα παρέχω συνδέσμους σε σελίδες που θα σας βοηθήσουν να κατανοήσετε πώς να τα χρησιμοποιήσετε.

Ας δούμε στην εργαλειοθήκη μου

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

• Το Integration Testing with Maven περιγράφει πώς μπορούμε να ρυθμίσουμε μια έκδοση Maven με δοκιμές ενοποίησης και μονάδων σε διαφορετικούς καταλόγους.
• Ξεκινώντας με το Gradle: Η δοκιμή ενσωμάτωσης με την προσθήκη TestSets καλύπτει το ίδιο και για το Gradle.

Τώρα είστε έτοιμοι να ρίξετε μια πιο προσεκτική ματιά στα εργαλεία μου. Τα έχω χωρίσει σε κατηγορίες για να σας διευκολύνω στην πλοήγηση.

Λοιπόν, εδώ είναι 12 εργαλεία που χρησιμοποιώ για την ενοποίηση και τη δοκιμή μονάδων.

Τρέξιμο τεστ

Το AssertJ παρέχει ένα ευέλικτο API για τη σύνταξη ισχυρισμών με χρήσιμα μηνύματα σφάλματος, βελτιώνει την αναγνωσιμότητα του κώδικα δοκιμής και σας επιτρέπει να μετατρέπετε τις δοκιμές σε εκτελέσιμες προδιαγραφές που συμμορφώνονται με την επιθυμητή γλώσσα για συγκεκριμένο τομέα.

Επιπροσθέτως:

• Η χρήση του Hamcrest στο Testing καλύπτει τον τρόπο χρήσης του Hamcrest για τη σύνταξη δοκιμών, καθώς και τον τρόπο επέκτασης των δυνατοτήτων του με προσαρμοσμένες μονάδες.
• Η μετατροπή των ισχυρισμών σε γλώσσα συγκεκριμένης περιοχής εξηγεί πώς μπορείτε να δημιουργήσετε προσαρμοσμένους ισχυρισμούς στο AssertJ.
• Συγγραφή καθαρών δοκιμών: Αντικατάσταση ισχυρισμών με γλώσσα συγκεκριμένης περιοχής. Εξηγεί γιατί πρέπει να αντικαταστήσουμε τους τυπικούς ισχυρισμούς του JUnit με τους δικούς μας που χρησιμοποιούν σωστή γλώσσα για συγκεκριμένο τομέα.

Δοκιμή κώδικα πρόσβασης δεδομένων

Γρήγορη βάση δεδομένων, χρήσιμη για τη σύνταξη δοκιμών ολοκλήρωσης που εκτελούνται τοπική μηχανήπρογραμματιστής.

Μια επέκταση στο JUnit που μπορεί να χρησιμοποιηθεί για την προετοιμασία της βάσης δεδομένων σε μια γνωστή κατάσταση πριν από την εκτέλεση κάθε δοκιμής ολοκλήρωσης και τη συμπλήρωση της βάσης δεδομένων με τα απαραίτητα δεδομένα. Το DbUnit έχει τα μειονεκτήματά του, αλλά είναι πολύ χρήσιμο εργαλείο, το οποίο σας επιτρέπει να διαχωρίσετε τα δεδομένα δοκιμής και τον κωδικό δοκιμής.

Επιπροσθέτως:

• περιγράφει τα βασικά στοιχεία του DbUnit που πρέπει να γνωρίζετε για να γράψετε δοκιμές χρησιμοποιώντας το DbUnit.
• παρέχει πέντε κανόνες για τη σύνταξη των καλύτερων δοκιμών για τον κωδικό πρόσβασης δεδομένων.

Ενώ έψαχνα για δοκιμαστικές εργασίες για προγραμματιστές Java, συνάντησα έναν ενδιαφέρον ιστότοπο (οι χρήστες του Avast δεν πρέπει να πάνε, ανιχνεύεται Trojan σενάριο, άλλοι είναι προφανώς εντάξει) - http://www.betterprogrammer.com. Δοκιμάζει τα προσόντα των προγραμματιστών Java με τον πιο απλό τρόπο, αλλά με αυτόματο τρόπο: προσφέρεται η εγγραφή πολλών λειτουργιών (μεθόδων) αυξανόμενης πολυπλοκότητας και η αντιγραφή του κώδικα στο TextArea. Στη συνέχεια, η μηχανή του ιστότοπου κάνει κάτι με τις εργασίες (όχι λιγότερο από μια δοκιμή μονάδας), υπολογίζει έναν συγκεκριμένο δείκτη πιστοποίησης με βάση τα κριτήρια "ταχύτητα-ποιότητα" και δίνει την τελική βαθμολογία με την ακόλουθη μορφή:

Μετά αρχίζουν οι ερωτήσεις. Εγώ ο ίδιος προγραμματίστηκα σε Java για δεύτερη φορά στη ζωή μου (και επομένως απλά παρέλειψα πολύπλοκες εργασίες), οπότε το 82% σε αυτό το τεστ αντιστοιχεί στο επίπεδο προγραμματιστής χωρίς Java. Πόσο, λοιπόν, θα πρέπει να προσλάβει ο Java Junior, ο Java Programmer και ακόμη περισσότερο ο Java Senior;! Από ποιο αποτέλεσμα μπορείτε να περιμένετε παρόνπρογραμματιστής java - 90, 95, 99; Και τέλος, τι γίνεται αν ο «προγραμματιστής» σκοράρει λιγότερο από 82, αλλά παρόλα αυτά κάνει αίτηση για κάποιο είδος εργασίας;!

Οι δοκιμές δεν είναι πάντα διασκεδαστικές και ενδιαφέρουσες. Αυτή η διαδικασία είναι συνήθως αρκετά χρονοβόρα και μερικές φορές γεμάτη μονότονη δουλειά. Φαίνεται ότι πρόσφατα οι προγραμματιστές χρησιμοποίησαν τυπική έξοδο ή ένα πρόγραμμα εντοπισμού σφαλμάτων για να δοκιμάσουν τάξεις java.

Σε αυτό το άρθρο θα περιγράψω τη βιβλιοθήκη JUnit 4, η οποία απλοποιεί και αυτοματοποιεί πολύ τη διαδικασία σύνταξης τεστ.

Για να δείξουμε τις κύριες δυνατότητες του JUnit Framework, ας γράψουμε μια πρωτόγονη τάξη στην Java και ας την κοροϊδέψουμε. Αυτή η κλάση θα έχει δύο μεθόδους - την εύρεση του παραγοντικού ενός μη αρνητικού αριθμού και του αθροίσματος δύο αριθμών. Επιπλέον, η παρουσία κλάσης θα περιέχει έναν μετρητή κλήσεων μεθόδου.

Δημόσια κλάση MathFunc ( κλήσεις int; δημόσια int getCalls() ( επιστροφή κλήσεων

Τώρα ας γράψουμε Unit tests. Για να γίνει αυτό, θα δημιουργήσουμε μια κλάση με μια σειρά από μεθόδους δοκιμής. Φυσικά, μια κλάση μπορεί επίσης να περιέχει συνηθισμένες βοηθητικές μεθόδους. Προκειμένου ο δοκιμαστικός δρομέας να προσδιορίσει ποιος είναι ποιος, οι μέθοδοι δοκιμής πρέπει να σχολιάζονται με @Test.

Ένας σχολιασμός μπορεί να έχει τις ακόλουθες παραμέτρους:

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

Εάν θέλετε να υποδείξετε ότι μια συγκεκριμένη δοκιμή πρέπει να παραλειφθεί, τότε σημειώστε την με τον σχολιασμό @Ignore. Αν και μπορείτε απλά να αφαιρέσετε τον σχολιασμό @Test.

Μπορεί να υπάρχουν φορές που χρειάζεστε κάποιο πλαίσιο, όπως προ-δημιουργημένες παρουσίες κλάσης, για να εκτελέσετε κάθε δοκιμαστική περίπτωση. Και μετά την εκτέλεση, πρέπει να απελευθερώσετε τους δεσμευμένους πόρους. Σε αυτήν την περίπτωση θα χρειαστείτε τους σχολιασμούς @Before και @After. Η μέθοδος με την ένδειξη @Before θα εκτελείται πριν από κάθε δοκιμαστική περίπτωση και η μέθοδος με την ένδειξη @After θα εκτελείται μετά από κάθε δοκιμαστική περίπτωση.

Εάν η προετοιμασία και η αποδέσμευση πόρων πρέπει να γίνει μόνο μία φορά - αντίστοιχα, πριν και μετά από όλες τις δοκιμές - τότε χρησιμοποιήστε ένα ζευγάρι σχολιασμών @BeforeClass και @AfterClass.

Και εδώ είναι η ίδια η δοκιμαστική τάξη με πολλά σενάρια δοκιμής:

Δημόσια τάξη MathFuncTest ( ιδιωτικά μαθηματικά MathFunc; @Before public void init() ( math = new MathFunc(); ) @After public void tearDown() ( math = null; ) @Test δημόσιες κλήσεις κενού() ( assertEquals(0, math .getCalls()); math.factorial(1); assertEquals(1, math.getCalls()); math.factorial(1); assertEquals(2, math.getCalls()); ) @Test public void factorial() ( assertTrue(math.factorial(0) == 1); assertTrue(math.factorial(1) == 1); assertTrue(math.factorial(5) == 120); ) @Test(αναμενόμενο = IllegalArgumentException.class) public void factorialNegative() ( math.factorial(-1); ) @Ignore @Test public void todo() ( assertTrue(math.plus(1, 1) == 3); ) )

Η μέθοδος κλήσεων ελέγχει την εγκυρότητα του μετρητή κλήσεων. Η παραγοντική μέθοδος ελέγχει εάν το παραγοντικό υπολογίζεται σωστά για ορισμένες τυπικές τιμές. Η μέθοδος factorialNegative ελέγχει ότι θα δημιουργηθεί ένα IllegalArgumentException για αρνητικές παραγοντικές τιμές. Η μέθοδος todo θα αγνοηθεί. Δοκιμάστε να αφαιρέσετε τον σχολιασμό @Ignore όταν πειραματίζεστε με τον κώδικα.

Η μέθοδος assertTrue ελέγχει εάν το αποτέλεσμα μιας έκφρασης είναι αληθές. Μερικές άλλες μέθοδοι που μπορεί να σας φανούν χρήσιμες:

• assertEquals - το αναμενόμενο αποτέλεσμα και το ληφθέν αποτέλεσμα ταιριάζουν.
• assertNull - το αποτέλεσμα της έκφρασης είναι null.
• assertNotNull - το αποτέλεσμα της έκφρασης είναι διαφορετικό από το null.
• assertSame - τα αναμενόμενα και τα ληφθέντα αντικείμενα είναι το ίδιο αντικείμενο.
• αποτυχία - η μέθοδος δημιουργεί μια εξαίρεση AssertionError - την προσθέτουμε εκεί που δεν πρέπει να πάει η εκτέλεση του προγράμματος.

Στο δικό μας σύγχρονος κόσμοςΤα IDE μπορούν να βρουν και απλώς να εκτελέσουν δοκιμές σε ένα έργο. Τι γίνεται όμως αν θέλετε να τα εκτελέσετε χειροκίνητα χρησιμοποιώντας κώδικα προγράμματος. Για να το κάνετε αυτό, μπορείτε να χρησιμοποιήσετε το Runner.Υπάρχουν εκδόσεις κειμένου - junit.textui.TestRunner, εκδόσεις γραφικών - junit.swingui.TestRunner, junit.awtui.TestRunner.

Αλλά λίγο περισσότερο σύγχρονη μέθοδοςείναι η χρήση της κλάσης JUnitCore. Προσθέστε την ακόλουθη κύρια μέθοδο στην κλάση MathFuncTest:

Δημόσιο στατικό κενό main(String args) Exception ( JUnitCore runner = new JUnitCore(); Αποτέλεσμα αποτελέσματος = runner.run(MathFuncTest.class) System.out.println("run tests: " + result.getRunCount()); System.out.println("αποτυχημένες δοκιμές: " + result.getFailureCount()); System.out.println("αγνοημένες δοκιμές: " + result.getIgnoreCount()); System.out.println("επιτυχία: " + αποτέλεσμα .ήταν επιτυχές()); )

Και το αποτέλεσμα εκτέλεσης:

Εκτέλεση δοκιμών: 3 αποτυχημένες δοκιμές: 0 αγνοημένες δοκιμές: 1 επιτυχία: αληθές

Σε περισσότερα προηγούμενες εκδόσειςΓια να γραφτεί μια κλάση δοκιμής JUnit, ήταν απαραίτητο να δημιουργηθεί ένας απόγονος του junit.framework.TestCase. Στη συνέχεια, ήταν απαραίτητο να οριστεί ένας κατασκευαστής που να παίρνει ως παράμετρο ένα String - το όνομα της μεθόδου - και να το μεταβιβάσει στη γονική κλάση. Κάθε μέθοδος δοκιμής έπρεπε να ξεκινά με τη δοκιμή του προθέματος. Οι μέθοδοι setUp και tearDown χρησιμοποιήθηκαν για την προετοιμασία και την αποδέσμευση πόρων. Με λίγα λόγια, φρίκη. Λοιπόν, τώρα όλα είναι απλά, ναι.

Αυτά για σήμερα. Είμαι σίγουρος ότι το JUnit Framework θα σας βοηθήσει πολύ. Σχόλια και ερωτήσεις σχετικά με το άρθρο είναι ευπρόσδεκτα.