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

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

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

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

Ας ρίξουμε μια ματιά στην εργαλειοθήκη μου

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

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

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

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

Τρέξιμο τεστ

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

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

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

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

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

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

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

• περιγράφει τα βασικά στοιχεία του 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 για αρνητικές τιμές του facotrial. Η μέθοδος todo θα αγνοηθεί. Εξετάστε το ενδεχόμενο να αφαιρέσετε τον σχολιασμό @Ignore καθώς πειραματίζεστε με τον κώδικα.

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

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

Στο δικό μας σύγχρονος κόσμοςΤα IDE μπορούν να βρουν και να εκτελέσουν εύκολα δοκιμές σε ένα έργο. Τι γίνεται όμως αν θέλετε να τα εκτελέσετε χειροκίνητα χρησιμοποιώντας κώδικα προγράμματος. Για να το κάνετε αυτό, μπορείτε να χρησιμοποιήσετε το Runner "th. Υπάρχουν κείμενο - 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 θα σας βοηθήσει πολύ. Σχόλια και ερωτήσεις σχετικά με το άρθρο είναι ευπρόσδεκτα.