C'est le cinquième de la série Spring Boot. Cette fois, j'expliquerai ** comment stuber la source ** avec un petit changement par rapport au passé.
Je pense que le plus courant est ** Mockito dans UT ou moqueur par wiremock dans FT **. Si vous bootRun, chaque maquette ne fonctionnera pas, vous pouvez donc avoir des problèmes avec l'échec de la communication HTTP ou ne pas pouvoir vous connecter à la base de données.
Si vous faites un stub par la méthode que je vais introduire à partir de maintenant ** Il est possible d'utiliser des stubs dans certains environnements et d'accéder à l'API réelle uniquement dans l'environnement où l'API opposée existe **.
J'espère que cela sera utile pour ceux qui en ont besoin! !!
Quel type de méthode faut-il utiliser pour créer le stub source? ** Enregistrez la classe stub avec le même nom que la classe que vous souhaitez stub dans le conteneur DI, ajoutez @Primary et remplacez-la **, Je le ferai.
Elle apparaît plusieurs fois dans mon article, mais j'utilise ** l'API de recherche par code postal **. Comme son nom l'indique, il s'agit d'une API qui renvoie des informations d'adresse dans le corps de la réponse lorsque vous demandez un code postal sur un paramètre de requête.
Pour l'implémentation, voir ici. BootRun et frappons quel type de résultat sera retourné.
Essayez d'abord de demander une adresse existante. Vous avez obtenu avec succès le code postal et le code de préfecture. Le système normal ressemble à ceci.
Mais que faire si vous demandez une adresse inexistante?
Bien sûr, si vous saisissez un code postal qui n'existe pas, vous obtiendrez une réponse vide **.
… Et si vous deviez lancer cette application dans un environnement où ** l'API de recherche par code postal n'existe pas? ** ** Inutile de dire que peu importe le code postal que vous demandez, vous obtiendrez une erreur 404 ** et ce sera inutile.
Faisons un ** stub et traitons-le ** pour un tel cas! !!
Je pense que c'est plus facile à imaginer en regardant la classe d'implémentation. Tout d'abord, mettez la classe d'implémentation.
MockClient.java
@Configuration // (1)
public class MockClient {
@Bean // (1)
@Primary // (1)
public GetAddressApiClient mockGetAddressApiClient(RestTemplateBuilder restTemplateBuilder,
ResponseHandlerInterceptor interceptor) {
return new MockGetAddressApiClient(restTemplateBuilder, interceptor);
}
static class MockGetAddressApiClient extends GetAddressApiClient { // (2)
MockGetAddressApiClient(RestTemplateBuilder restTemplateBuilder,
ResponseHandlerInterceptor interceptor) {
super(restTemplateBuilder, interceptor);
}
@Override
public GetAddressApiResponse request(String zipCode) {
return new GetAddressApiResponse( // (3)
"200",
"",
Arrays.asList(
new GetAddressApiResponse.Result(
"zipcode",
"prefcode",
"address1",
"address2",
"address3",
"kana1",
"kana2",
"kana3"
),
new GetAddressApiResponse.Result(
"zipcode",
"prefcode",
"address1",
"address2",
"address3",
"kana1",
"kana2",
"kana3"
)
)
);
}
}
}
J'expliquerai chaque point!
@ Configuration
+@ Primary (@Bean)
La définition du bean par annotation est possible dans Spring, et la classe stub est enregistrée dans le conteneur DI avec @ Configuration
+ @ Bean
utilisé à ce moment-là.
Cependant, pour le moment, puisque le vrai GetAddressApiClient
est également enregistré, ** il y a deux beans avec le même nom, et Spring lève une exception. ** **
Utilisez ** @ Primary
** pour le contourner!
En conséquence, celui avec «@ Primary» sera prioritaire.
En d'autres termes, ** la classe stub sera toujours utilisée **.
Ensuite, créez la classe stub elle-même. Comme mentionné ci-dessus, cette fois, il est nécessaire d'enregistrer le bean avec le même type que la classe réelle. Pour ce faire, ** créez une classe stub en héritant de la classe réelle **. C'est relativement important.
super
pour omettre le constructeur.@ Override
la méthode et définir la valeur de retourLe reste est la définition de la valeur de retour.
Dans ce cas, remplacez la méthode request
pour renvoyer toute valeur de retour que vous souhaitez.
Démarrons et frappons. Puisque la réponse écrite dans le stub est renvoyée, Il semble qu'il ait été poignardé avec succès!
… Mais voici une autre question. ** "Ce stub fonctionne toujours, alors peut-être que la vraie classe ne fonctionne pas?" ** …C'est vrai. Cette fois, au contraire, c'est devenu une application qui ne fonctionne qu'avec des stubs.
Alors ** Rendons possible d'utiliser correctement la chose réelle et le stub pour chaque environnement! !! ** **
** Ajoutez @ Profile
à la classe stub **.
En conséquence, la classe stub sera enregistrée DI uniquement dans l'environnement spécifié, et la classe stub ne sera pas enregistrée DI dans l'environnement non spécifié (≒ la vraie chose fonctionnera) **.
MockClient.java
@Configuration
@Profile("dev")
public class MockClient {
//réduction
}
Dans le cas ci-dessus, ce sera une classe stub uniquement dans l'environnement de développement
, et la vraie classe Client fonctionnera dans d'autres environnements!
Merci d'avoir regardé jusqu'au bout! Quand j'ai cherché, j'ai trouvé qu'il n'y avait pas beaucoup d'articles comme celui-ci, alors j'espère que cela aide quelqu'un!
Nous apprécions vos commentaires et commentaires!