You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/features/MP_JWT.md
+11-1Lines changed: 11 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,8 +41,18 @@ As the `@RolesAllowed` annotations imply, anyone can access the `GET /data/ping`
41
41
When MicroShed Testing will automatically generate and configure a pair of JWT secrets for the `ApplicationContainer` container. Then a test client may access these endpoints using the `@JwtConfig` annotation on injected REST clients as follows:
Copy file name to clipboardExpand all lines: docs/features/Walkthrough.md
+75-56Lines changed: 75 additions & 56 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -8,7 +8,7 @@ Have you ever toiled with creating mock objects for unit tests? How about custom
8
8
9
9
One of the great benefits of Docker is that we get a nice consistent package that contains everything down to the OS, meaning it’s portable to any hardware. Great, so lets use this to get consistent testing environments too!
10
10
11
-
# Starting point
11
+
# Starting application
12
12
13
13
Assume we have a basic JAX-RS application that can perform create, update, and delete
14
14
operations on 'Person' data objects. It may look something like this:
@@ -45,7 +45,7 @@ Now assume we also have simple Dockerfile in our repository that packages up our
45
45
```
46
46
FROM openliberty/open-liberty:full-java8-openj9-ubi
47
47
COPY src/main/liberty/config /config/
48
-
ADDbuild/libs/myservice.war /config/dropins
48
+
ADDtarget/myservice.war /config/dropins
49
49
```
50
50
51
51
It doesn't really matter what's in the Dockerfile. What matters is we can start it using Docker and interact with it over HTTP or some other protocol.
@@ -75,13 +75,48 @@ Given the above application code, we can start by adding maven dependencies:
75
75
</dependencies>
76
76
```
77
77
78
+
## EnablingJUnitJupiter with MavenFailsafe
79
+
80
+
If you have never used JUnitJupiter (JUnit5) before with integration tests, there are a few important things to note:
81
+
82
+
1.The package import for `@Test` is now `import org.junit.jupiter.api.Test;`
83
+
2.Bydefault, test classnames must match the pattern: `**/IT*.java`, `**/*IT.java`, or `**/*ITCase.java`
84
+
3. The `maven-failsafe-plugin` must be added to your `pom.xml` with configuration similar to the following:
85
+
86
+
```xml
87
+
<project>
88
+
[...]
89
+
<build>
90
+
<plugins>
91
+
<plugin>
92
+
<groupId>org.apache.maven.plugins</groupId>
93
+
<artifactId>maven-failsafe-plugin</artifactId>
94
+
<version>2.22.0</version>
95
+
<executions>
96
+
<execution>
97
+
<goals>
98
+
<goal>integration-test</goal>
99
+
<goal>verify</goal>
100
+
</goals>
101
+
</execution>
102
+
</executions>
103
+
</plugin>
104
+
</plugins>
105
+
</build>
106
+
[...]
107
+
</project>
108
+
```
109
+
78
110
## Starting the application container
79
111
80
112
Next, we create the basic test classand inject the REST endpoint we want to test:
@@ -101,8 +136,13 @@ Launching defaultServer (Open Liberty 19.0.0.8/wlp-1.0.31.cl190820190813-1136) o
101
136
Here we can see that the application is available at `http://localhost:9080/myservice/`, which means the context root is `/myservice`. Now we can add that information to the test class like so:
By default, containers pipe logs to SLF4j. This is certainly worth setting up, because coallates all container logs to the test output. This makes it easy to correlate what was going on inside of your application during each test method. One way to set up SFL4j is by adding the following dependency:
131
-
132
-
```xml
133
-
<dependency>
134
-
<groupId>org.slf4j</groupId>
135
-
<artifactId>slf4j-log4j12</artifactId>
136
-
<version>1.7.26</version>
137
-
<scope>test</scope>
138
-
</dependency>
139
-
```
140
-
141
-
And then create a file at `src/test/resources/log4j.properties` with a valid Log4j configuration. For example:
@@ -162,10 +175,10 @@ By default, MicroShed Testing will poll the application container via HTTP on it
162
175
However, our application does not respond at this endpoint, so we need to configure a different endpoint for readiness. Since the `getAllPeople()` method is bound to the `GET /myservice/people/` endpoint and does not depend on any particular state, it is a good candidate for a readiness check. We can configure the readiness check endpoint like this:
publicstaticApplicationContainer app = new ApplicationContainer()
180
+
.withAppContextRoot("/myservice")
181
+
.withReadinessPath("/myservice/people");
169
182
```
170
183
171
184
Alternatively, if your application runtime supports MicroProfileHealth2.0, it will have a standard readiness endpoint at `/heath/ready`, which will return `HTTP200` when the application is available.
@@ -176,38 +189,44 @@ Now that the setup is complete, we are ready to write some test methods! First w
176
189
reading the result back.
177
190
178
191
```java
179
-
@Test
180
-
public void testGetPerson() {
181
-
// This invokes an HTTP POST request to the running container, which triggers
182
-
// the PersonService#createPerson endpoint and returns the generated ID
183
-
Long bobId = personSvc.createPerson("Bob", 24);
184
-
185
-
// Using the generated ID, invoke an HTTP GET request to read the record we just created
186
-
// The JSON response will be automatically converted to a 'Person' object using JSON-B
187
-
Person bob = personSvc.getPerson(bobId);
188
-
189
-
assertEquals("Bob", bob.name);
190
-
assertEquals(24, bob.age);
191
-
assertNotNull(bob.id);
192
-
}
192
+
import org.junit.jupiter.api.Test;
193
+
// ...
194
+
195
+
@Test
196
+
publicvoidtestGetPerson() {
197
+
// This invokes an HTTP POST request to the running container, which triggers
198
+
// the PersonService#createPerson endpoint and returns the generated ID
199
+
Long bobId = personSvc.createPerson("Bob", 24);
200
+
201
+
// Using the generated ID, invoke an HTTP GET request to read the record we just created
202
+
// The JSON response will be automatically converted to a 'Person' object using JSON-B
203
+
Person bob = personSvc.getPerson(bobId);
204
+
205
+
assertEquals("Bob", bob.name);
206
+
assertEquals(24, bob.age);
207
+
assertNotNull(bob.id);
208
+
}
193
209
```
194
210
195
211
Next, we can write a negative test case that checks behavior for when someone requests a `Person` with an invalid ID.
196
212
197
213
```java
198
-
@Test
199
-
publicvoid testGetUnknownPerson() {
200
-
// This invokes an HTTP GET request to get a person with ID -1, which does not exist
201
-
// asserts that the application container returns an HTTP 404 (not found) exception
0 commit comments