Test-starter (dept44-starter-test)

Denna starter tillhandahåller stödfunktionalitet och beroenden för att skriva tester i tjänster. För att använda den, lägg till följande i tjänstens pom.xml:

<dependency>
	<groupId>se.sundsvall.dept44</groupId>
	<artifactId>dept44-starter-test</artifactId>
	<scope>test</scope>
</dependency>

Bland de tredjepartsberoenden som följer med startern kan bl.a. följande nämnas:

App-tester

För app-tester tillhandahåller startern ett enkelt sätt att starta upp en WireMock-server på en slumpmässig, ledig port:

@WireMockAppTestSuite(                                        [1]
    files = "classpath:/MyFirstAppTest/",                     [2]
    classes = Application.class                               [3]
)
class MyFirstAppTest extends AbstractAppTest {                [4]

    @Test
    void test1_successful() throws Exception {
        setupCall()
            .withServicePath("/path/to/endpoint")             [5]
            .withHttpMethod(HttpMethod.POST)                  [6]
            .withRequest("some-request.json")                 [7]
            .withExpectedResponseStatus(HttpStatus.OK)        [8]
            .withExpectedResponse("expected-response.json")   [9]
            .sendRequestAndVerifyResponse();
    }
}

[1] Annotering som anger att WireMock ska startas upp för aktuell testklass.
[2] Pekar ut var WireMock hittar resurser (mappningar etc.).För varje test-metod kommer metodnamnet att byggas på denna sökväg, t.ex. .../MyFirstAppTest/test1_successful/....
[3] Pekar ut vilken klass som ska användas för att ladda context:en för testet. Kommer oftast att vara tjänstens applikationsklass, d.v.s. den klass som innehåller en main-metod och som används för att starta tjänsten.
[4] Test-basklassen AbstractAppTest innehåller funktionalitet för att bl.a. enkelt kunna sätta upp ett testfall, mot en förväntad endpoint ([5]) med en viss HTTP-metod ([6]), ett request ([7]), en förväntad HTTP-status ([8]) och ett förväntat svar ([9]).

Rekommenderat är att placera app-tester under src/integration-test/java och deras resurser under src/integration-test/resources.

Porten som WireMock-servern startas på exponeras som wiremock.server.port, och man bör då peka om eventuella URL:er för t.ex. integrationer att gå mot den lokala datorn och den porten. t.ex. integration.messaging.base-url=http://localhost:${wiremock.server.port}/...

JsonUnit används av ramverket för att hantera både request-matchning och response-verifiering.

Här kommer exempel på hur man kan använda detta:

mapping.json (wiremock request matchning)

{
  "request": {
    ...
    "bodyPatterns" : [ {
      "equalToJson" : "{ \"someAttribute\": \"${json-unit.any-string}\"  }",
      "ignoreArrayOrder" : true,
      "ignoreExtraElements" : true
    } ]
    ...
  },
  ...
}

response.json (response-verifiering)

ResourceLoaderExtension

Ramverket tillhandahåller en JUnit-extension för att enkelt kunna läsa in resurser i sina tester:

[1] Aktiverar stöd för övriga annoteringar ([2], [3] och [4]) för att läsa in resurser.
[2] @Load-annoteringen används för att peka ut vilken resurs på classpath:en som ska läsas in i den annoterade parametern. Anges inget värde i “as”-attributet, deserialiseras resursen som en String till den annoterade parametern.
[3] ResourceType.JSON i “as”-attributet används i @Load för att läsa in en resurs och försöka deserialisera den från JSON till den annoterade parametern.
[4] ResourceType.XML i “as”-attributet används i @Load för att läsa in en resurs och försöka deserialisera den från XML till den annoterade parametern.