0
votes

Besoin de démarrer Tomcat Server pour Test Junit Test Case

Bonjour, j'ai écrit un étui à essai de juint pour l'API de repos avec httpurirequest. Le boîtier de test donne le résultat approprié, mais le problème est que je dois exécuter le serveur Tomcat pour tester le cas de test Junit. Pourquoi ??

Voici mon code: P>

package com.dataguise.webservices;

import static org.junit.jupiter.api.Assertions.*;

import org.apache.http.HttpResponse;
import org.apache.http.client.ClientProtocolException;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.client.methods.HttpUriRequest;
import org.apache.http.impl.client.HttpClientBuilder;
import org.apache.http.util.EntityUtils;
import org.junit.jupiter.api.Test;
import java.io.IOException;
import com.dataguise.webservices.beans.DgException;


class RestAPIsTest {

    final String versionNumber = "v1";

    final String baseUrl = "http://localhost:10181/dgcontroller/services/restAPIs/";
    
    final String sessionId = "2";

@Test
    public void idpsTest() throws ClientProtocolException, IOException {
        HttpUriRequest request = new HttpGet(baseUrl + versionNumber + "/idps");
        request.addHeader("sessionId", sessionId);
        HttpResponse httpResponse = HttpClientBuilder.create().build().execute(request);
        System.out.println(">>>>>>>>>>>>>>>." + httpResponse.getStatusLine().getStatusCode());
        
        assertEquals(200, httpResponse.getStatusLine().getStatusCode());
        
        // Getting Json From Http Response
        String json = EntityUtils.toString(httpResponse.getEntity());
        System.out.println(">>>>>>>>>>>>>>>." + json);
    }
}

java mockito junit5

0 commentaires

3 Réponses :

2
votes

Je pense que vous avez mal compris la signification des "tests d'unité". Si vous faites une demande HTTP à un serveur exécutant, vous testez l'ensemble du serveur et non seulement une unité distincte.

Si vous souhaitez tester la logique à l'intérieur de votre contrôleur, créez simplement l'objet du contrôleur manuellement et appelez la méthode correspondante.

0 commentaires

0
votes

Le serveur est nécessaire car vous effectuez des tests contre les URL.

La seule façon de le faire est de se moquer du serveur. Il existe de nombreuses bibliothèques moqueuses différentes pour Java, comme Mockito ou EasyMock, mais ils vous permettent tous de fournir de fausses réponses du serveur.

Dans le cas de test que vous avez collé, il n'a pas de sens d'effectuer de tels tests, car vous semblez vérifier que le serveur réel répond et ne fait rien avec la réponse. La moqueur du serveur est très utile pour tester les clients API, mais vous ne semblez pas tester cela.

Vous avez deux options ici:

Testez la fonctionnalité à l'intérieur du point d'extrémité avec un test d'unité sans impliquer le serveur du tout
Créez des crochets pré-intégration et post-intégration qui démarre et arrête le serveur pour vous pendant le test. Vous pouvez facilement faire cela avec Maven ou Gradle (check Apache Tomcat Server avant le test d'intégration )

1 commentaires

pouvez-vous s'il vous plaît me fournir du code que je peux se moquer du serveur

0
votes

Si vous souhaitez tester vos points d'extrémité API, Spring fournit diverses annotations et différentes manières dans lesquelles vous pouvez tester votre application. Comme:

Vous pouvez démarrer le serveur pendant le test de test, initialiser le contexte de l'application de ressort, puis tester l'API en le frappant pour affirmer le résultat. LI>
Vous pouvez simplement utiliser l'annotation de printemps @springboottest code> avec @Autoconfiguremockmvc code> pour configurer le contexte de l'application sans démarrer le serveur pour tester votre application à la fin de votre application. LI >
Une autre approche lorsque vous ne souhaitez pas tester toute l'application, mais il suffit de tester le calque Web consiste à utiliser l'annotation @webmvctest code>. Dans ce cas, vous devez vous moquer de la couche de service et de tout autre haricot qui pourrait être nécessaire pour obtenir le résultat souhaité. LI> ol> Vous pouvez utiliser l'annotation @springboottest code> pour indiquer le printemps qu'il doit démarrer le serveur et avoir le contexte de l'application configuré pour exécuter votre test. P> Le @springboottest code> Annotation indique le démarrage à la recherche d'une principale Classe de configuration (une avec @springbooPlication code>, par exemple) et utiliser cela pour lancer un contexte d'application de ressort. P> blockQquote> Dans ce cas, vous n'aurez pas à démarrer votre serveur manuellement Spring prendra soin de tout et une fois que les tests sont effectués, il arrêtera le serveur aussi. Je n'ai pas essayé de compiler ou d'exécuter le code mais utiliser comme: p> xxx pré> Ceci devrait fonctionner aussi longtemps que vous avez la dépendance suivante dans votre pom.xml code>: p> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> <exclusions> <exclusion> <groupId>org.junit.vintage</groupId> <artifactId>junit-vintage-engine</artifactId> </exclusion> </exclusions> </dependency>

2 commentaires

En fait, je n'utilise pas la chaussure de printemps

Excuses. Quel cadre et quelle version utilisez-vous alors?