Μενού

Κορυφαίες 12 ερωτήσεις συνέντευξης Mockito (Συνέντευξη Mocking Framework)

  • Κύριος
  • Αλλα
  • Κορυφαίες 12 ερωτήσεις συνέντευξης Mockito (Συνέντευξη Mocking Framework)

top 12 mockito interview questions

Δοκιμάστε Το Όργανο Μας Για Την Εξάλειψη Των Προβλημάτων

Οι πιο συχνές ερωτήσεις συνέντευξης Mockito για να σπάσει τη συνέντευξη Mockito Mocking:

Στο προηγούμενο σεμινάριό μας, μάθαμε Ιδιωτικές, στατικές και άκυρες μέθοδοι χλευασμού . Διαβάστε το ολοκληρωμένα εκπαιδευτικά σεμινάρια για το Mockito για μια σαφή κατανόηση του πλαισίου Mockito.

Αυτό το άρθρο καλύπτει τις πιο συχνές ερωτήσεις σχετικά με τις συνεντεύξεις στο πλαίσιο του Mockito Mocking.

Κάθε προγραμματιστής ή QA αναμένεται να γνωρίζει τα βασικά του Mocking προκειμένου να γράφει τις περισσότερες δοκιμές λευκού πλαισίου (ή δοκιμές μονάδας) με ευκολία και να χλευάζει τις εξαρτήσεις για βελτιωμένη κάλυψη κώδικα και μεγαλύτερη εμπιστοσύνη στην εφαρμογή.

Ερωτήσεις συνέντευξης Mockito

Οι πιο δημοφιλείς ερωτήσεις συνέντευξης Mockito με λεπτομερείς απαντήσεις

Παρακάτω αναφέρονται οι πιο συχνές ερωτήσεις σχετικά με το Mocking Frameworks.

Ε # 1) Γιατί χρειαζόμαστε χλευασμό;

Απάντηση: Υπάρχουν πολλές περιπτώσεις χρήσης κοροϊδίας που βοηθούν στη δοκιμή μονάδας του κώδικα μεμονωμένα και καθιστούν τη δοκιμή εξαιρετικά επαναλαμβανόμενη και προβλέψιμη.

Το χλευασμό απαιτείται γενικά όταν:

προς την) Το υπό δοκιμή στοιχείο έχει εξαρτήσεις που δεν έχουν ακόμη εφαρμοστεί ή η εφαρμογή βρίσκεται σε εξέλιξη.

Ένα καλό παράδειγμα μπορεί να είναι ένα τελικό σημείο REST API το οποίο θα είναι διαθέσιμο αργότερα κάποια στιγμή, αλλά το έχετε καταναλώσει στον κώδικα μέσω εξάρτησης.

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

σι) Το στοιχείο ενημερώνει την κατάσταση στο σύστημα.

Παράδειγμα: Κλήσεις DB - δεν θα θέλατε να ενημερώσετε το DB σας με δεδομένα που προορίζονται μόνο για δοκιμές. Αυτό μπορεί να οδηγήσει σε καταστροφή των δεδομένων, επιπλέον, η διαθεσιμότητα του DB είναι μια άλλη πρόκληση κατά την εκτέλεση του τεστ.

Έτσι, για να αποφευχθεί μια τέτοια συμπεριφορά, οι κλήσεις DB θα μπορούσαν να κοροϊδεύονται στο υπό δοκιμή στοιχείο. Ως εκ τούτου, δεν υπάρχει άμεση σύζευξη του DB και του υπό δοκιμή εξαρτήματος.

Q # 2) Διαφορά μεταξύ doReturn και thenReturn.

Απάντηση: Το Mockito παρέχει δύο διαφορετικές σύνταξη για τη δημιουργία στελεχών όπως:

  • doReturn και στη συνέχειαReturn
  • doNothing (όχι τότε τίποτα)
  • doThrow και μετάThrow

Και οι δύο αυτές μέθοδοι εγκαθιστούν stubs και μπορούν να χρησιμοποιηθούν για τη δημιουργία / setup stubs και θα μπορούσαν να χρησιμοποιηθούν εναλλακτικά κατά καιρούς.

υπόλοιπες ερωτήσεις συνέντευξης και απαντήσεις για έμπειρους

Λοιπόν, πώς διαφέρουν και τα δύο;

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

Ας το καταλάβουμε με ένα παράδειγμα:

Ας υποθέσουμε μια μέθοδο getItemDetails επί mockedItemService που επιστρέφει ένα αντικείμενο τύπου ItemSku. Έτσι με τότε επιστροφή, δεν θα μπορείτε να επιστρέψετε οτιδήποτε άλλο εκτός από τον τύπο ItemSku, αλλά με το doReturn, μπορείτε να ρυθμίσετε το στέλεχος για να επιστρέψετε οτιδήποτε και ο έλεγχος θα αποτύχει (ή θα ρίξει μια εξαίρεση) κατά την εκτέλεση.

// έργα

when (mockedItemService.getItemDetails(123)).thenReturn(new ItemSku());

// ρίχνει εξαίρεση χρόνου μεταγλώττισης

when (mockedItemService.getItemDetails(123)).thenReturn(expectedPrice);

// με το doReturn, και οι δύο ρυθμίσεις για το στέλεχος λειτουργούν καθώς δεν είναι ασφαλές για μεταγλώττιση.

// εδώ προσπαθούμε να επιστρέψουμε ένα αντικείμενο τύπου διπλού που εξακολουθεί να λειτουργεί και δεν εμφανίζει προειδοποίηση μεταγλώττισης.

doReturn (expectedPrice).when(mockedItemService.getItemDetails(123)); doReturn (new ItemSku()).when(mockedItemService.getItemDetails(123));

σι) Μια άλλη σημαντική διαφορά μεταξύ αυτών των 2 τρόπων στο στέλεχος είναι για τα αντικείμενα Mocked, εκτός από την ασφάλεια μεταγλώττισης δεν υπάρχει μεγάλη διαφορά.

Ωστόσο, για κατασκοπευτικά αντικείμενα, το είδος 'τότεReturn' δεν θα λειτουργήσει, καθώς θα έχει ως αποτέλεσμα την κλήση της πραγματικής μεθόδου πριν από την επιστροφή του stubbed ως κλήση και όχι σε Mock, αλλά στο Spy που τυλίγει μια παρουσία πραγματικού αντικειμένου .

Ας υποθέσουμε ότι υπάρχει ένας κατάσκοπος που ονομάζεται spiedObject και έχει μια μέθοδο δοκιμής Μέθοδος που επιστρέφει έναν ακέραιο, και στη συνέχεια για να ρυθμίσετε ένα στέλεχος σε αυτό θα πρέπει να χρησιμοποιήσετε το doReturn αντί για το τότεReturn.

doReturn (10).when(spiedObject.testMethod());

Q # 3) Πότε και γιατί πρέπει να χρησιμοποιείται ένας κατάσκοπος;

Απάντηση: Το Spy είναι ένας τύπος μερικής παρωδίας που υποστηρίζεται από τον Mockito.

Αυτό ουσιαστικά σημαίνει ότι είναι ένας τύπος παρουσίας όπου:

προς την) Όταν δεν έχει ρυθμιστεί κανένα ψεύτικο, οποιαδήποτε αλληλεπίδραση σε κατάσκοπους οδηγεί στην κλήση των πραγματικών μεθόδων. Αλλά εξακολουθεί να σας επιτρέπει να επαληθεύσετε τις αλληλεπιδράσεις με το κατασκοπευτικό αντικείμενο όπως - ήταν μια μέθοδος που ονομάστηκε πραγματικά, πόσες φορές κλήθηκε η μέθοδος, ποια ήταν τα επιχειρήματα με τα οποία κλήθηκε η μέθοδος κ.λπ.

σι) Σας δίνει την ευελιξία για τη ρύθμιση μερικών χλευασμάτων.

Για παράδειγμα, εάν έχετε ένα αντικείμενο με 2 μεθόδους - τη μέθοδο 1 και τη μέθοδο 2 και θέλετε να κληθεί η μέθοδος 1 και η μέθοδος 2 να κοροϊδευτεί. Οι κατάσκοποι παρέχουν αυτό το είδος εγκατάστασης.

Έτσι, η διαφορά ανάμεσα σε ένα ψεύτικο και ένα στέλεχος με απλούς όρους είναι - ένα πλαστό δημιουργείται από έναν τύπο και όχι από μια παρουσία, ενώ ένα στέλεχος τυλίγει μια πραγματική παρουσία του αντικειμένου της κλάσης.

Q # 4) Γιατί δεν μπορούν να γελοιοποιηθούν οι στατικές μέθοδοι χρησιμοποιώντας το Mockito;

κυκλική συνδεδεμένη λίστα c ++

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

Οι στατικές μέθοδοι μοιάζουν περισσότερο με τον διαδικαστικό κώδικα και χρησιμοποιούνται συνήθως σε παλαιότερα συστήματα.

Οι βιβλιοθήκες πλαστών δημιουργούν συνήθως χλευασμούς με τη δημιουργία δυναμικής παρουσίας κατά το χρόνο εκτέλεσης, είτε μέσω διεπαφών είτε μέσω κληρονομιάς και καθώς η στατική μέθοδος δεν σχετίζεται με κάποια συγκεκριμένη παρουσία, δεν είναι δυνατόν για πλαστά πλαίσια (όπως mockito, easy mock κ.λπ.) να κοροϊδεύουν τις Στατικές μεθόδους.

Πλαίσια όπως το PowerMock τα οποία έχουν υποστήριξη για στατικές μεθόδους εκτελούν χειρισμό bytecode κατά το χρόνο εκτέλεσης, προκειμένου να παραπλανήσουν τις στατικές μεθόδους.

Ε # 5) Ποια είναι η ανάγκη επαλήθευσης της κλήσης του πλαστή;

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

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

Στην ουσία, μας επιτρέπει να επαληθεύσουμε τη ρύθμιση της δοκιμής και το αναμενόμενο αποτέλεσμα με πιο ισχυρό τρόπο.

Q # 6) Τι είναι ένας καλός κωδικός που ελέγχεται;

Απάντηση:

Λίγα σημεία σχετικά με τον ελεγχόμενο κώδικα (που σημαίνει ότι μπορεί εύκολα να ελεγχθεί μονάδα) περιλαμβάνουν:

  • Μειωμένος αριθμός εξαρτήσεων ή στενή σύνδεση - Παράδειγμα: Οι εξαρτήσεις πρέπει να εγχέονται και όχι να δημιουργούνται άμεσα.
  • Κωδικός που συμμορφώνεται με το SRP (Αρχή της ενιαίας ευθύνης) - Αυτό σημαίνει ουσιαστικά ότι η τάξη δεν πρέπει να έχει πολλαπλούς λόγους αλλαγής. Η τήρηση του SRP αποτρέπει τις τάξεις που δημιουργούν εξάρτηση από τον εαυτό της και διατηρεί τον κώδικα συνεκτικό και καθαρό.
  • Λιγότερη / Ελάχιστη χρήση στατικών μεθόδων και τελικών τάξεων - Αυτά γενικά υποδηλώνουν μυρωδιές κώδικα και συνδέονταν κυρίως με τον παλαιό κώδικα.

Q # 7) Ποιοι είναι οι περιορισμοί του Mockito;

Απάντηση: Το Mockito είναι ένα πλαίσιο επιλογής για τα περισσότερα έργα που βασίζονται σε Java. Είναι εύκολο να εφαρμοστεί, να διαβαστεί και να κατανοηθεί.

Μερικά από τα μειονεκτήματα ή τους περιορισμούς όσον αφορά τη λειτουργικότητα είναι:

  • Η αδυναμία του να πλαστογραφήσει τις στατικές μεθόδους.
  • Οι κατασκευαστές, οι ιδιωτικές μέθοδοι και οι τελικές τάξεις δεν μπορούν να χλευαστούν.

Ε # 8) Ποια πλαίσια μπορούν να υποστηρίξουν τις πλαστές ιδιωτικές και στατικές μεθόδους;

Απάντηση: Πλαίσια όπως το PowerMockito (επεκτάσεις του Mockito framework), το JMockit κ.λπ. παρέχουν μέσα για να πλαστογραφούν ιδιωτικές και στατικές μεθόδους.

Q # 9) Mocking / Stubbing προεπιλεγμένες μέθοδοι στο Interface στην Java 8.

Απάντηση: Με την εφαρμογή των προεπιλεγμένων μεθόδων Java 8 στο Interface, το Mockito παρέχει υποστήριξη εκτός κουτιού για να πλαστογραφήσει αυτές τις προεπιλεγμένες μεθόδους. (Λάβετε υπόψη ότι αυτή η υποστήριξη παρουσιάστηκε από το Mockito 2 και μετά).

Αυτές οι μέθοδοι μπορούν να κοροϊδεύονται / να μαχαιρώνονται όπως και άλλες μέθοδοι τάξης ή διεπαφής.

Ε # 10) Πώς μπορεί να επαληθευτεί η παραγγελία επίκλησης στο Mockito;

Απάντηση: Όταν θέλετε να επαληθεύσετε τη σειρά με την οποία κλήθηκαν οι χλευασμοί, το Mockito's ' Για να Μπορεί να χρησιμοποιηθεί διεπαφή.

Κατά τη διάρκεια της δοκιμής, πρέπει απλώς να ρυθμίσετε / δημιουργήσετε ένα αντικείμενο Inorder, παραθέτοντας μια λίστα με ψεύτικα αντικείμενα στα οποία πρέπει να εξακριβωθεί η σειρά των χλευασμάτων (εάν υπάρχουν πολλές μέθοδοι στην ίδια πλαστή και δεν υπάρχει άλλη πλαστή που χρειάζεται για επαλήθευση, τότε αρκεί να αναφέρουμε την πλαστή τάξη μόνο μία φορά).

Εξετάστε το τεστ που δίνεται παρακάτω που καθορίζει ένα αντικείμενο του InOrder και αναφέρει 2 εμφανίσεις mockDatabaseImpl

@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); }

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

public void calculateSumAndStore(String studentId, int() scores) { int total = 0; for(int score : scores) { total = total + score; } // write total to DB databaseImpl.updateScores(studentId, total); databaseImpl.getGrade(total); }

Όπως φαίνεται παραπάνω, η βάση δεδομένων Impl κάνει τις πρώτες κλήσεις updateScores και στη συνέχεια τις κλήσεις getGrade.

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

Στο παραπάνω παράδειγμα, εάν αλλάξω τη σειρά των ισχυρισμών, τότε θα προκαλέσει την αποτυχία του τεστ με εξαίρεση το 'VerificationInOrderFailure'.

Μετά την αλλαγή της σειράς επιβεβαίωσης, ο κώδικας φαίνεται όπως φαίνεται παρακάτω:

@Test public void calculateSumAndStore_withValidInput_verifyMockOrder() { // Arrange studentScores = new StudentScoreUpdates(mockDatabaseImpl); int() scores = {60,70,90}; Mockito.doNothing().when(mockDatabaseImpl).updateScores(anyString(), anyInt()); Mockito.doReturn('A').when(mockDatabaseImpl).getGrade(anyInt()); InOrder inorder = inOrder(mockDatabaseImpl); // Act studentScores.calculateSumAndStore('Student1', scores); // Assert inorder.verify(mockDatabaseImpl).updateScores(anyString(),anyInt()); inorder.verify(mockDatabaseImpl).getGrade(anyInt()); }

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

'VerificationInOrderFailure' org.mockito.exceptions.verification.VerificationInOrderFailure:
Επαλήθευση σε αποτυχία παραγγελίας
Ζητήθηκε αλλά δεν επικαλέστηκε:
mockDatabaseImpl.updateScores (
isA (java.lang.String),
isA (java.lang.Integer)

Ε # 11) Επιστροφή πολλαπλών τιμών έναντι διαδοχικών κλήσεων μεθόδου

Απάντηση: Για να επιστρέψετε διαφορετικές τιμές για πολλαπλές προσκλήσεις της ίδιας μεθόδου, το Mockito παρέχει 3 προσεγγίσεις όπως δίνεται παρακάτω:

προς την) Χρήση διαχωρισμένου με κόμμα: Αυτό λειτουργεί με το τότεReturn.

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

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A','B', 'C');

Αυτό σημαίνει ότι όταν οι μέθοδοι getGrade κληθούν στην υπό δοκιμή μέθοδο, η πρώτη επίκληση θα επιστρέψει 'Α', η δεύτερη επίκληση θα επιστρέψει 'Β' και ούτω καθεξής.

σι) Διαδοχικά τότε Επιστροφή: Αυτή είναι μια προσέγγιση που συνδέεται με τις δηλώσεις τότε Επιστροφής. Η εφαρμογή αλυσοδεμένων κλήσεων στο ίδιο παράδειγμα θα φαίνεται όπως φαίνεται παρακάτω.

when (mockDatabaseImpl.getGrade( anyInt ())).thenReturn('A').thenReturn('B').thenReturn('C');

γ) Διαδοχική doReturn: Η τελευταία προσέγγιση χρησιμοποιεί το doReturn σε αλυσοδεμένη μορφή όπως παραπάνω.

πώς να περάσετε τον πίνακα ως παράμετρο στο java
doReturn ('A').doReturn('B').doReturn('C').when(mockDatabaseImpl).getGrade( anyInt ())

Ε # 12) Ποιοι είναι οι διαφορετικοί τύποι πλαστών πλαισίων και πώς λειτουργούν;

Απάντηση: Οι τύποι του πλαισίου Mocking και πώς λειτουργούν εξηγούνται παρακάτω.

Υπάρχουν γενικά 2 κατηγορίες πλαστών πλαισίων:

  1. Βάσει διακομιστή μεσολάβησης - Παράδειγμα, Mockito, EasyMock κ.λπ.
  2. Βάσει κωδικού - Παράδειγμα, PowerMock, JMockit κ.λπ.

Ας συγκρίνουμε και τα δύο αυτά πλαίσια με διαφορετικές παραμέτρους.

Βάσει διακομιστή μεσολάβησηςΒάσει κωδικού
ΑπλάΠιο απλό και εύκολο στη χρήσηΜπορεί να περιλαμβάνει πολύπλοκη λογική λογικής ρύθμισης
Τρόπος δημιουργίαςΔημιουργείται ένας διακομιστής μεσολάβησης ή ένα ψεύτικο αντικείμενο που πραγματικά δεν απαιτεί παρουσία κλάσης / διεπαφήςΠεριλαμβάνει ουσιαστικά τη δημιουργία αντικειμένων και κατά το χρόνο εκτέλεσης χειρίζεται τις εμφανίσεις για τη συμπεριφορά που κοροϊδεύτηκε
ΛειτουργικότηταΧλευάσουμε μαθήματα και διεπαφέςΕκτός από τις τάξεις και τις διασυνδέσεις, επιτρέπει πλαστικές στατικές μεθόδους, τελικές τάξεις κ.λπ.
Εξάρτηση JavaΔεν συνδυάζεται πολύ καλά με τις εκδόσεις javaΔεδομένου ότι αυτά τα πλαίσια περιλαμβάνουν χειρισμό bytecode, είναι στενά συνδεδεμένα και ενδέχεται να μην είναι συμβατά προς τα πίσω / προς τα εμπρός σε όλες τις εκδόσεις java.
ΠαραδείγματαMockito, EasyMock κ.λπ.PowerMock, JMockit κ.λπ.

συμπέρασμα

Το περιεχόμενο που καλύπτεται σε αυτό το άρθρο εξυπηρετεί βασικές συζητήσεις γύρω από τα πλαίσια Mocking και συγκεκριμένα την προετοιμασία συνέντευξης του Mockito.

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

Ελπίζω, απολαύσατε ολόκληρο το φάσμα των σεμιναρίων σε αυτήν τη σειρά Mockito.

Καλή μάθηση.

Εκπαιδευτικό πρόγραμμα PREV | Πρώτο σεμινάριο

Συνιστώμενη ανάγνωση

^