Πίσω Μέρος

Δημιουργία με εμπιστοσύνη: Ένας οδηγός για τις δοκιμές JUnit

Με την πρόοδο της τεχνολογίας και της βιομηχανίας να μετακινούνται από το μοντέλο καταρράκτη στο Agile και τώρα στο DevOps, οι αλλαγές και οι βελτιώσεις σε μια εφαρμογή αναπτύσσονται στην παραγωγή τη στιγμή που γίνονται. Καθώς ο κώδικας αναπτύσσεται τόσο γρήγορα στην παραγωγή, πρέπει να είμαστε σίγουροι ότι οι αλλαγές μας λειτουργούν και επίσης ότι δεν παραβιάζουν προϋπάρχουσα λειτουργικότητα.

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

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

Υπάρχουν πολλά διαθέσιμα πλαίσια για κάθε γλώσσα προγραμματισμού. Θα επικεντρωθούμε στη μονάδα γραφής και στον έλεγχο ενοποίησης για μια εφαρμογή ιστού που είναι γραμμένη Ιάβα Το εαρινό πλαίσιο.

είναι διευθυντής διευθυντής μιας εταιρείας

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

Ας προχωρήσουμε σε δοκιμές μονάδας Java την άνοιξη χρησιμοποιώντας το πλαίσιο JUnit. Θα ξεκινήσουμε με κάτι που ίσως έχετε ακούσει: κοροϊδεύω.

Τι είναι το χλευασμό και πότε μπαίνει στην εικόνα;

Ας υποθέσουμε ότι έχετε μια τάξη, CalculateArea, η οποία έχει μια συνάρτηση calculateArea(Type type, Double... args) που υπολογίζει την περιοχή ενός σχήματος του δεδομένου τύπου (κύκλος, τετράγωνο ή ορθογώνιο.)

Ο κώδικας πηγαίνει κάπως έτσι σε μια κανονική εφαρμογή που δεν χρησιμοποιεί ένεση εξάρτησης:

public class CalculateArea { SquareService squareService; RectangleService rectangleService; CircleService circleService; CalculateArea(SquareService squareService, RectangleService rectangeService, CircleService circleService) { this.squareService = squareService; this.rectangleService = rectangeService; this.circleService = circleService; } public Double calculateArea(Type type, Double... r ) { switch (type) { case RECTANGLE: if(r.length >=2) return rectangleService.area(r[0],r[1]); else throw new RuntimeException('Missing required params'); case SQUARE: if(r.length >=1) return squareService.area(r[0]); else throw new RuntimeException('Missing required param'); case CIRCLE: if(r.length >=1) return circleService.area(r[0]); else throw new RuntimeException('Missing required param'); default: throw new RuntimeException('Operation not supported'); } } }

public class SquareService { public Double area(double r) { return r * r; } } public class RectangleService { public Double area(Double r, Double h) { return r * h; } } public class CircleService { public Double area(Double r) { return Math.PI * r * r; } } public enum Type { RECTANGLE,SQUARE,CIRCLE; }

Τώρα, αν θέλουμε να δοκιμάσουμε τη μονάδα calculateArea() της τάξης CalculateArea, τότε το κίνητρό μας πρέπει να είναι να ελέγξουμε αν το switch λειτουργούν περιπτώσεις και συνθήκες εξαίρεσης. Δεν πρέπει να ελέγξουμε εάν οι υπηρεσίες σχήματος επιστρέφουν τις σωστές τιμές, επειδή όπως αναφέρθηκε προηγουμένως, το κίνητρο της δοκιμής μονάδας μιας συνάρτησης είναι να ελέγξει τη λογική της συνάρτησης, όχι τη λογική των κλήσεων που πραγματοποιεί η συνάρτηση.

Επομένως, θα κοροϊδέψουμε τις τιμές που επιστρέφονται από μεμονωμένες συναρτήσεις υπηρεσίας (π.χ. rectangleService.area() και θα δοκιμάσουμε τη λειτουργία κλήσης (π.χ. CalculateArea.calculateArea()) με βάση αυτές τις πλαστές τιμές.

Μια απλή δοκιμαστική θήκη για την υπηρεσία ορθογωνίου — δοκιμή ότι calculateArea() πράγματι καλεί rectangleService.area() με τις σωστές παραμέτρους - θα μοιάζει με αυτό:

import org.junit.Assert; import org.junit.Before; import org.junit.Test; import org.mockito.Mockito; public class CalculateAreaTest { RectangleService rectangleService; SquareService squareService; CircleService circleService; CalculateArea calculateArea; @Before public void init() { rectangleService = Mockito.mock(RectangleService.class); squareService = Mockito.mock(SquareService.class); circleService = Mockito.mock(CircleService.class); calculateArea = new CalculateArea(squareService,rectangleService,circleService); } @Test public void calculateRectangleAreaTest() { Mockito.when(rectangleService.area(5.0d,4.0d)).thenReturn(20d); Double calculatedArea = this.calculateArea.calculateArea(Type.RECTANGLE, 5.0d, 4.0d); Assert.assertEquals(new Double(20d),calculatedArea); } }

Δύο κύριες γραμμές που πρέπει να σημειώσετε εδώ είναι:

rectangleService = Mockito.mock(RectangleService.class); —Αυτό δημιουργεί ένα πλαστό, το οποίο δεν είναι πραγματικό αντικείμενο, αλλά ένα πλαστό.
Mockito.when(rectangleService.area(5.0d,4.0d)).thenReturn(20d); —Αυτό λέει ότι, όταν κοροϊδεύονται, και το rectangleService του αντικειμένου area Η μέθοδος καλείται με τις καθορισμένες παραμέτρους και μετά επιστρέψτε 20d.

Τώρα, τι συμβαίνει όταν ο παραπάνω κώδικας αποτελεί μέρος μιας εφαρμογής Spring;

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.stereotype.Component; @Component public class CalculateArea { SquareService squareService; RectangleService rectangleService; CircleService circleService; public CalculateArea(@Autowired SquareService squareService, @Autowired RectangleService rectangeService, @Autowired CircleService circleService) { this.squareService = squareService; this.rectangleService = rectangeService; this.circleService = circleService; } public Double calculateArea(Type type, Double... r ) { // (same implementation as before) } }

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

@Component: Δημιουργεί φασόλι τύπου CalculateArea
@Autowired: Αναζητά τα φασόλια rectangleService, squareService και circleService και τα εγχέει στο φασόλι calculatedArea

Ομοίως, δημιουργούμε φασόλια και για άλλες κατηγορίες:

import org.springframework.stereotype.Service; @Service public class SquareService { public Double area(double r) { return r*r; } }

import org.springframework.stereotype.Service; @Service public class CircleService { public Double area(Double r) { return Math.PI * r * r; } }

import org.springframework.stereotype.Service; @Service public class RectangleService { public Double area(Double r, Double h) { return r*h; } }

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

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

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

Σε περίπτωση έγχυσης πεδίου, ο κωδικός έχει ως εξής:

@Component public class CalculateArea { @Autowired SquareService squareService; @Autowired RectangleService rectangleService; @Autowired CircleService circleService; public Double calculateArea(Type type, Double... r ) { // (same implementation as before) } }

Σημείωση: Δεδομένου ότι χρησιμοποιούμε έγχυση πεδίου, δεν υπάρχει ανάγκη για παραμετροποιημένο κατασκευαστή, επομένως το αντικείμενο δημιουργείται χρησιμοποιώντας την προεπιλεγμένη και οι τιμές ορίζονται χρησιμοποιώντας τον μηχανισμό έγχυσης πεδίου.

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

public class CalculateAreaTest { @Mock RectangleService rectangleService; @Mock SquareService squareService; @Mock CircleService circleService; @InjectMocks CalculateArea calculateArea; @Before public void init() { MockitoAnnotations.initMocks(this); } @Test public void calculateRectangleAreaTest() { Mockito.when(rectangleService.area(5.0d,4.0d)).thenReturn(20d); Double calculatedArea = this.calculateArea.calculateArea(Type.RECTANGLE, 5.0d, 4.0d); Assert.assertEquals(new Double(20d),calculatedArea); } }

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

Πρώτον, ο τρόπος με τον οποίο χλευάζουμε τα αντικείμενά μας: Χρησιμοποιούμε @Mock σχολιασμοί μαζί με initMocks() για να δημιουργήσετε χλευασμούς. Δεύτερον, εισάγουμε χλευασμούς στο πραγματικό αντικείμενο χρησιμοποιώντας @InjectMocks μαζί με initMocks().

Αυτό γίνεται μόνο για τη μείωση του αριθμού των γραμμών κώδικα.

Τι είναι οι δρομείς δοκιμής και ποιοι τύποι δρομέων υπάρχουν;

Στο παραπάνω δείγμα, ο βασικός δρομέας που χρησιμοποιείται για την εκτέλεση όλων των δοκιμών είναι BlockJUnit4ClassRunner που ανιχνεύει όλους τους σχολιασμούς και εκτελεί όλες τις δοκιμές ανάλογα.

Αν θέλουμε περισσότερη λειτουργικότητα, τότε μπορεί να γράψουμε ένα προσαρμοσμένο δρομέα. Για παράδειγμα, στην παραπάνω τάξη δοκιμής, εάν θέλουμε να παραλείψουμε τη γραμμή MockitoAnnotations.initMocks(this); τότε θα μπορούσαμε να χρησιμοποιήσουμε έναν διαφορετικό δρομέα που είναι χτισμένος πάνω από το BlockJUnit4ClassRunner, π.χ. MockitoJUnitRunner.

Χρησιμοποιώντας το MockitoJUnitRunner, δεν χρειάζεται καν να προετοιμάσουμε τα χλευάσματα και να τα εγχύσουμε. Αυτό θα γίνει από MockitoJUnitRunner μόνο διαβάζοντας σχολιασμούς.

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

Μερική χλευασμός

Όταν θέλουμε ένα αντικείμενο στην τάξη δοκιμής να χλευάζει κάποιες μεθόδους, αλλά και να καλέσει κάποιες πραγματικές μεθόδους, τότε χρειαζόμαστε μερική χλευασμό. Αυτό επιτυγχάνεται μέσω @Spy στο JUnit.

Σε αντίθεση με τη χρήση @Mock, με @Spy, δημιουργείται ένα πραγματικό αντικείμενο, αλλά οι μέθοδοι αυτού του αντικειμένου μπορούν να παραπλανηθούν ή μπορούν να κληθούν - ό, τι χρειαζόμαστε.

Για παράδειγμα, εάν το area μέθοδος στην τάξη RectangleService καλεί μια επιπλέον μέθοδο log() και πραγματικά θέλουμε να εκτυπώσουμε αυτό το αρχείο καταγραφής, τότε ο κώδικας αλλάζει σε κάτι όπως το παρακάτω:

@Service public class RectangleService { public Double area(Double r, Double h) { log(); return r*h; } public void log() { System.out.println('skip this'); } }

Εάν αλλάξουμε το @Mock σχολιασμός rectangleService να @Spy, και επίσης να κάνουμε κάποιες αλλαγές κώδικα όπως φαίνεται παρακάτω, τότε στα αποτελέσματα θα δούμε πραγματικά να εκτυπώνονται τα αρχεία καταγραφής, αλλά η μέθοδος area() θα χλευαστούν. Δηλαδή, η αρχική λειτουργία εκτελείται αποκλειστικά για τις παρενέργειές της. Οι τιμές επιστροφής αντικαθίστανται από πλαστές.

@RunWith(MockitoJUnitRunner.class) public class CalculateAreaTest { @Spy RectangleService rectangleService; @Mock SquareService squareService; @Mock CircleService circleService; @InjectMocks CalculateArea calculateArea; @Test public void calculateRectangleAreaTest() { Mockito.doCallRealMethod().when(rectangleService).log(); Mockito.when(rectangleService.area(5.0d,4.0d)).thenReturn(20d); Double calculatedArea = this.calculateArea.calculateArea(Type.RECTANGLE, 5.0d, 4.0d); Assert.assertEquals(new Double(20d),calculatedArea); } }

Πώς θα δοκιμάσουμε ένα `Controller` ή `RequestHandler`;

Από όσα μάθαμε παραπάνω, ο κωδικός δοκιμής ενός ελεγκτή για το παράδειγμά μας θα ήταν κάτι σαν το παρακάτω:

import org.springframework.beans.factory.annotation.Autowired; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; import org.springframework.stereotype.Controller; import org.springframework.web.bind.annotation.RequestMapping; import org.springframework.web.bind.annotation.RequestMethod; import org.springframework.web.bind.annotation.RequestParam; import org.springframework.web.bind.annotation.ResponseBody; @Controller public class AreaController { @Autowired CalculateArea calculateArea; @RequestMapping(value = 'api/area', method = RequestMethod.GET) @ResponseBody public ResponseEntity calculateArea( @RequestParam('type') String type, @RequestParam('param1') String param1, @RequestParam(value = 'param2', required = false) String param2 ) { try { Double area = calculateArea.calculateArea( Type.valueOf(type), Double.parseDouble(param1), Double.parseDouble(param2) ); return new ResponseEntity(area, HttpStatus.OK); } catch (Exception e) { return new ResponseEntity(e.getCause(), HttpStatus.INTERNAL_SERVER_ERROR); } } }

import org.junit.Assert; import org.junit.Test; import org.junit.runner.RunWith; import org.mockito.InjectMocks; import org.mockito.Mock; import org.mockito.Mockito; import org.mockito.junit.MockitoJUnitRunner; import org.springframework.http.HttpStatus; import org.springframework.http.ResponseEntity; @RunWith(MockitoJUnitRunner.class) public class AreaControllerTest { @Mock CalculateArea calculateArea; @InjectMocks AreaController areaController; @Test public void calculateAreaTest() { Mockito .when(calculateArea.calculateArea(Type.RECTANGLE,5.0d, 4.0d)) .thenReturn(20d); ResponseEntity responseEntity = areaController.calculateArea('RECTANGLE', '5', '4'); Assert.assertEquals(HttpStatus.OK,responseEntity.getStatusCode()); Assert.assertEquals(20d,responseEntity.getBody()); } }

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

Αυτός ο κωδικός είναι καλύτερος:

import org.junit.Before; import org.junit.Test; import org.junit.runner.RunWith; import org.mockito.InjectMocks; import org.mockito.Mock; import org.mockito.Mockito; import org.springframework.test.context.junit4.SpringJUnit4ClassRunner; import org.springframework.test.web.servlet.MockMvc; import org.springframework.test.web.servlet.request.MockMvcRequestBuilders; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status; import static org.springframework.test.web.servlet.setup.MockMvcBuilders.standaloneSetup; @RunWith(SpringJUnit4ClassRunner.class) public class AreaControllerTest { @Mock CalculateArea calculateArea; @InjectMocks AreaController areaController; MockMvc mockMvc; @Before public void init() { mockMvc = standaloneSetup(areaController).build(); } @Test public void calculateAreaTest() throws Exception { Mockito .when(calculateArea.calculateArea(Type.RECTANGLE,5.0d, 4.0d)) .thenReturn(20d); mockMvc.perform( MockMvcRequestBuilders.get('/api/area?type=RECTANGLE¶m1=5¶m2=4') ) .andExpect(status().isOk()) .andExpect(content().string('20.0')); } }

Εδώ μπορούμε να δούμε πώς MockMvc αναλαμβάνει την εκτέλεση πραγματικών κλήσεων API. Έχει επίσης κάποιους ειδικούς ταιριαστές όπως status() και content() που διευκολύνουν την επικύρωση του περιεχομένου.

Δοκιμή ενοποίησης Java με χρήση JUnit και Mocks

Τώρα που γνωρίζουμε ότι λειτουργούν μεμονωμένες ενότητες του κώδικα, ας βεβαιωθούμε ότι αλληλεπιδρούν επίσης μεταξύ τους όπως περιμένουμε.

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

τα στοιχεία στα οποία γίνεται έκκληση για σχεδιασμό στο σύμπαν περιλαμβάνουν ποια από τα παρακάτω

Για αυτό, ορίζουμε όλα τα φασόλια σε μια τάξη, ας πούμε TestConfig.java:

import org.springframework.context.annotation.Bean; import org.springframework.context.annotation.Configuration; @Configuration public class TestConfig { @Bean public AreaController areaController() { return new AreaController(); } @Bean public CalculateArea calculateArea() { return new CalculateArea(); } @Bean public RectangleService rectangleService() { return new RectangleService(); } @Bean public SquareService squareService() { return new SquareService(); } @Bean public CircleService circleService() { return new CircleService(); } }

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

import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.content; import static org.springframework.test.web.servlet.result.MockMvcResultMatchers.status; import static org.springframework.test.web.servlet.setup.MockMvcBuilders.standaloneSetup; @RunWith(SpringJUnit4ClassRunner.class) @ContextConfiguration(classes = {TestConfig.class}) public class AreaControllerIntegrationTest { @Autowired AreaController areaController; MockMvc mockMvc; @Before public void init() { mockMvc = standaloneSetup(areaController).build(); } @Test public void calculateAreaTest() throws Exception { mockMvc.perform( MockMvcRequestBuilders.get('/api/area?type=RECTANGLE¶m1=5¶m2=4') ) .andExpect(status().isOk()) .andExpect(content().string('20.0')); } }

Μερικά πράγματα αλλάζουν εδώ:

@ContextConfiguration(classes = {TestConfig.class}) —Αυτό λέει την υπόθεση όπου βρίσκονται όλοι οι ορισμοί των φασολιών.
Τώρα αντί για @InjectMocks χρησιμοποιούμε:

@Autowired AreaController areaController;

Όλα τα υπόλοιπα παραμένουν τα ίδια. Εάν εντοπίσουμε σφάλματα στη δοκιμή, θα δούμε ότι ο κώδικας εκτελείται μέχρι την τελευταία γραμμή του area() μέθοδος στο RectangleService όπου return r*h υπολογίζεται. Με άλλα λόγια, τρέχει η πραγματική επιχειρηματική λογική.

Αυτό δεν σημαίνει ότι δεν υπάρχει χλευασμός των κλήσεων μεθόδου ή των κλήσεων βάσης δεδομένων στη δοκιμή ενοποίησης. Στο παραπάνω παράδειγμα, δεν χρησιμοποιήθηκε υπηρεσία ή βάση δεδομένων τρίτων, επομένως δεν χρειαζόταν να χρησιμοποιήσουμε χλευασμούς. Στην πραγματική ζωή, τέτοιες εφαρμογές είναι σπάνιες και συχνά θα χτυπήσουμε μια βάση δεδομένων ή ένα API τρίτου μέρους ή και τα δύο. Σε αυτήν την περίπτωση, όταν δημιουργούμε το φασόλι στο TestConfig τάξη, δεν δημιουργούμε το πραγματικό αντικείμενο, αλλά ένα πλαστό, και το χρησιμοποιούμε όπου χρειάζεται.

Μπόνους: Πώς να δημιουργήσετε δεδομένα τεστ μεγάλου αντικειμένου

Συχνά αυτό που σταματά τους προγραμματιστές back-end σε τεστ ενότητας ή δοκιμών ενοποίησης είναι τα δεδομένα δοκιμής που πρέπει να προετοιμάσουμε για κάθε δοκιμή.

Κανονικά εάν τα δεδομένα είναι αρκετά μικρά, με μία ή δύο μεταβλητές, τότε είναι εύκολο να δημιουργήσετε ένα αντικείμενο μιας δοκιμαστικής κατηγορίας δεδομένων και να εκχωρήσετε ορισμένες τιμές.

Για παράδειγμα, εάν περιμένουμε ένα πλαστό αντικείμενο να επιστρέψει ένα άλλο αντικείμενο, όταν καλείται μια συνάρτηση στο πλαστό αντικείμενο, θα κάναμε κάτι τέτοιο:

Class1 object = new Class1(); object.setVariable1(1); object.setVariable2(2);

Και μετά για να χρησιμοποιήσουμε αυτό το αντικείμενο, κάναμε κάτι τέτοιο:

Mockito.when(service.method(arguments...)).thenReturn(object);

Αυτό είναι καλό στα παραπάνω παραδείγματα JUnit, αλλά όταν οι μεταβλητές μέλους στα παραπάνω Class1 η τάξη συνεχίζει να αυξάνεται, και στη συνέχεια ο καθορισμός μεμονωμένων πεδίων γίνεται πολύ πόνος. Μερικές φορές μπορεί ακόμη και να συμβεί ότι μια τάξη έχει ένα άλλο μη πρωτόγονο μέλος της τάξης. Στη συνέχεια, η δημιουργία ενός αντικειμένου αυτής της κλάσης και ο καθορισμός μεμονωμένων απαιτούμενων πεδίων αυξάνει περαιτέρω την προσπάθεια ανάπτυξης μόνο για να επιτύχει κάποιο boilerplate.

Η λύση είναι να δημιουργήσετε ένα σχήμα JSON της παραπάνω κλάσης και να προσθέσετε τα αντίστοιχα δεδομένα στο αρχείο JSON μία φορά. Τώρα στην τάξη δοκιμής όπου δημιουργούμε το Class1 αντικείμενο, δεν χρειάζεται να δημιουργήσουμε το αντικείμενο με μη αυτόματο τρόπο. Αντ 'αυτού, διαβάζουμε το αρχείο JSON και, χρησιμοποιώντας το ObjectMapper, το χαρτογραφούμε στο απαιτούμενο Class1 τάξη:

ObjectMapper objectMapper = new ObjectMapper(); Class1 object = objectMapper.readValue( new String(Files.readAllBytes( Paths.get('src/test/resources/'+fileName)) ), Class1.class );

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

Βασικά στοιχεία JUnit: Πολλαπλές προσεγγίσεις και μεταβιβάσιμες δεξιότητες

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

Ανεξάρτητα από τη γλώσσα ή το πλαίσιο που χρησιμοποιούμε - ίσως ακόμη και οποιαδήποτε νέα έκδοση του Spring ή JUnit - η εννοιολογική βάση παραμένει η ίδια όπως εξηγείται στο παραπάνω σεμινάριο JUnit. Καλή δοκιμή!

Κατανόηση των βασικών

Πώς γράφετε ένα τεστ μονάδας στην Java;

Το JUnit είναι το πιο διάσημο πλαίσιο για τη σύνταξη τεστ μονάδας στην Java. Γράφετε μεθόδους δοκιμής που απαιτούν τις πραγματικές μεθόδους που πρέπει να δοκιμαστούν. Η δοκιμαστική θήκη επαληθεύει τη συμπεριφορά του κώδικα, επιβεβαιώνοντας την τιμή επιστροφής έναντι της αναμενόμενης τιμής, λαμβάνοντας υπόψη τις παραμέτρους που έχουν περάσει.

Ποιο είναι το καλύτερο πλαίσιο δοκιμών μονάδων για Java;

Η πλειονότητα των προγραμματιστών Java συμφωνούν ότι το JUnit είναι το καλύτερο πλαίσιο δοκιμών μονάδων. Είναι το de facto πρότυπο από το 1997, και σίγουρα έχει το μεγαλύτερο ποσό υποστήριξης σε σύγκριση με άλλα πλαίσια δοκιμών μονάδας Java.

Τι είναι η δοκιμαστική μονάδα στον προγραμματισμό;

Στη δοκιμή μονάδας, μεμονωμένες μονάδες (συχνά, οι μέθοδοι αντικειμένων θεωρούνται «μονάδα») δοκιμάζονται με αυτοματοποιημένο τρόπο.

Γιατί χρησιμοποιούμε τη δοκιμή JUnit;

Το τεστ JUnit χρησιμοποιείται για τον έλεγχο της συμπεριφοράς των μεθόδων μέσα σε τάξεις που έχουμε γράψει. Δοκιμάζουμε μια μέθοδο για τα αναμενόμενα αποτελέσματα και μερικές φορές τις περιπτώσεις εξαίρεσης - εάν η μέθοδος μπορεί να χειριστεί τις εξαιρέσεις με τον τρόπο που θέλουμε.