Wenn Sie sehr bequem für das Testen gegen APIs und in CI integrieren möchten, um jedes Commit zu überprüfen, ist das, das mit Spring Boot enthalten ist, definitiv die beste Wahl.
Schreiben Sie schnell einen Testfall
@Runwith (springrunner.class) @springboottest (webenvironment = springboottest.webenvironment.random_port) @ActiveProfile ({Profiles.env_it}) öffentliche Klasse DemointegrationTest {@autowired private fooService; @Test public void test () {System.out.println ("getestet"); }}Unter ihnen definiert Springboottest einige Konfigurationen beim Ausführen. Der obige Code verwendet zufällige Ports, und natürlich kann er auch die Ports wie diese vordefiniert
@Springboottest (WebEnvironment = SpringBoottest.Webenvironment.Defined_port, Properties = {"Server.port = 9990"})ActiveProfiles erzwingen die Verwendung des IT -Profils. Aus einer bewährten Praxis sollten die Adressen von Datenbanken oder anderen Ressourcenkomponenten, die vom IT -Profil konfiguriert sind, aus der Entwicklungs- oder Staging -Umgebung isoliert werden. Denn wenn ein IT durch viele Situationen läuft, müssen wir die Testdaten löschen.
Sie können feststellen, dass ein solcher Fall in einen gewünschten Dienst injiziert werden kann. Dies liegt daran, dass Spring den gesamten Kontext lädt, der der tatsächlichen laufenden Umgebung entspricht, einschließlich Datenbank, Cache und anderen Komponenten. Wenn Sie das Gefühl haben, dass Sie während des Tests nicht alle Ressourcen benötigen, können Sie die entsprechende Konfiguration im Profil löschen. Dies ist eine vollständige Betriebsumgebung. Der einzige Unterschied besteht darin, dass sie nach Abschluss des Anwendungsfalls automatisch heruntergefahren wird.
Testen Sie eine REST -API
Empfehlen Sie eine Bibliothek, um Gradle zu erweitern
testcompile 'io.rest-Asvala: REST-ARTEURIERT: 3.0.3'
Unterstützen Sie JsonPath, was sehr nützlich ist. Klicken Sie hier für bestimmte Dokumente
@SQL (scripts = "/testdata/users.sql")@testpublic void test001login () {String username =" [email protected] "; String password = "Demo"; JwtauthenticationRequest Request = new JwtthenticationRequest (Benutzername, Passwort); Antwort Antwort = gegeben (). ContentType (contentType.json) .body (request) .When (). Post ("/auth/login"). Dann () .StatusCode (httpstatus.ok.value ()) .extract () .Response (); AssertThat (Antwort.Path ("Token"), ist (isnull.notnullValue ())); Assertthat (Antwort.Path ("Ablauf"), ist (isnull.notnullValue ()));} @SQL wird verwendet, um vor dem Testen SQL -Insert -Testdaten durchzuführen. Beachten Sie, dass given().body() in ein Java-Objekt JWtauthenticationRequest übergeben wird, da Sie mit REST-ADERSURED automatisch Jackson verwenden, um das Objekt in eine JSON-Zeichenfolge zu serialisieren. Natürlich können Sie den umgebauten JSON auch in den Körper einfügen, der Effekt ist der gleiche.
Das Rückgabeergebnis wird durch eine Antwort erfasst, und dann können die Daten unter Verwendung von JSONPADE zur Überprüfung erhalten werden. Natürlich gibt es eine weitere intuitivere Art und Weise, die die vollständige Reaktion durch Response erhalten kann. Assstring () und sie dann zur Überprüfung in ein Java -Objekt zu Deserialisierung.
Zu diesem Zeitpunkt ist das grundlegendste es abgeschlossen. Durch das Hinzufügen eines Stufen -Gradle -Tests zu Jenkins können Sie jedes Mal, wenn der Code eingereicht wird, Tests durchführen.
Einige komplizierte Situationen
Gemischte Daten
Dies ist am einfachsten zu passieren. Ein Projekt hat viele Entwickler, und jeder Entwickler wird seinen eigenen IT -Fall schreiben. Was ist also, wenn es einen Einfluss zwischen den Daten gibt? Es ist leicht zu verstehen. In einem Szenario, in dem eine Testcharge schreibt, besteht beispielsweise die endgültige Überprüfungsmethode fest, ob die Datenmenge 10.000 Zeilen beträgt. Dann schrieb ein anderer Entwickler andere Fälle und fügte zufällig eine neue Daten zu dieser Tabelle hinzu, die sich in 10 W+1 Zeilen verwandelte, sodass der in Chargen geschriebene Fall nicht in der Lage wäre, zu entkommen.
Um diese Situation zu verhindern, verwenden wir jede Testklasse, um die Daten zu löschen. Da es sich um eine klassenbasierte Operation handelt, können Sie eine Basisklasse schreiben, um sie zu lösen.
@Runwith (springrunner.class) @springboottest (webenvironment = springboottest.webenvironment.random_port) @ActiveProfile ({Profies.env_it}) public abstrakte Klasse BaseInteInegationstest {private statische jdbctemplate jdbctemplate; @Autowired public void setDataSource (DataSource -DataSource) {jdbctemplate = new JdbCtemplate (DataSource); } @Value ("$ {local.server.port}") Protected Int Port; @Before public void setupenv () {restasured.port = port; Restasured.basepath = "/api"; Restasured.baseuri = "http: // localhost"; Restasured.config = restasured.config (). Httpclient (httpclientConfig.httpclientConfig (). } public void TearDownenv () {gegeben (). contentType (contentType.json) .When (). post ("/auth/logout"); } @AfterClass public static void CleanDB () löst SQLEXception aus {Ressourcenressource = new classpatResource ("/testData/CleanDB.SQL"); Connection Connection = jdbctemplate.getDataSource (). GetConnection (); Scriptutils.executesqlScript (Verbindung, Ressource); Connection.close (); }}@AfterClass verwendet JDBCTEMplate, um eine CleanDB.SQL auszuführen, die alle Testdaten auf diese Weise löscht.
@ Value("${local.server.port}") muss ebenfalls erwähnt werden, da der Port zufällig ist. REST-ADERSURD WISSE nicht, an welchen Port die Anfrage gesendet wird. Verwenden Sie hier @Value, um die aktuelle Portnummer zu erhalten, und stellen Sie sie auf die Lösung dieses Problems auf rindasce.port ein.
Verarbeitung gemeinsamer Daten
Wenn Sie eine vollständige Ausführung ausführen, kann es Dutzende von Klassen und Hunderten von Methoden erfordern. Was ist also, wenn einige Daten für alle Fälle erforderlich sind und erst dann gelöscht werden müssen, wenn alle Fälle ausgeführt wurden? Mit anderen Worten, diese Art der Datenreinigung basiert nicht auf dem Unterricht, sondern auf einem Lauf gleichzeitig. Zum Beispiel erste Benutzerdaten, Stadtbibliothek usw.
Wir haben einen cleveren Trick gespielt und Flyway benutzt
@Configuration@ConditionalOnClass ({dataSource.class}) öffentliche Klasse UpgradeAutoConfiguration {public static Final String flyway = "Flyway"; @Bean (name = flyway) @Profile ({env_it}) public upgraderService CleanAndupgradeService (DataSource DataSource) {Upgradeservice upgraderService = new FlywayUpgradeService (DataSource); try {upgraGeService.CleanandUpgrade (); } catch (Ausnahme ex) {logger.Error ("Flyway fehlgeschlagen!", Ex); } return Upgradeservice; }} Sie können sehen, dass Flyway, wenn das Profil ist, alle Tabellen fallen und das Upgrade -Skript nacheinander ausführen und so eine vollständige Datentabelle erstellen, die natürlich leer ist. Fügen Sie auf dem Testpfad des Projekts eine riesige Version von SQL hinzu, damit Flyway am Ende gemeinsame Testdaten einfügen kann, z. B. src/test/resources/db/migration/V999.0.1__Insert_Users.sql und lösen Sie verschiedene Datenprobleme perfekt.
Zusammenfassung
Die Verwendung des integrierten Testdienstes im Spring Boot kann die API schnell überprüfen. Ich muss den Dienst nicht starten und dann auf die manuelle Seite klicken, um meine API zu testen. Ich kommuniziere direkt mit meinen Front-End-Kollegen das Anforderungsformat und schreibe einen Fall, um ihn zu überprüfen.
Natürlich gibt es auch einen Nachteil dieser Methode, nämlich, dass es unpraktisch ist, das System zu testen. Zuvor wurden die API -Testfälle des Unternehmens von JMeter verfasst, was bei Leistungstests viel bequemer wäre.