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/quickstart/junit_4_quickstart.md
+20-9Lines changed: 20 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,10 +1,13 @@
1
1
# JUnit 4 Quickstart
2
2
3
-
It's easy to add Testcontainers to your project - let's walk through a quick example to see how.
3
+
This example shows the way you could use Testcontainers with JUnit 4.
4
+
5
+
!!! note
6
+
JUnit 4 is in [maintenance mode since 2025-05-31](https://github.com/junit-team/junit4), so we recommend using JUnit 5 or newer versions instead.
4
7
5
8
Let's imagine we have a simple program that has a dependency on Redis, and we want to add some tests for it.
6
9
In our imaginary program, there is a `RedisBackedCache` class which stores data in Redis.
7
-
10
+
8
11
You can see an example test that could have been written for it (without using Testcontainers):
9
12
10
13
<!--codeinclude-->
@@ -15,15 +18,16 @@ Notice that the existing test has a problem - it's relying on a local installati
15
18
This may work if we were sure that every developer and CI machine had Redis installed, but would fail otherwise.
16
19
We might also have problems if we attempted to run tests in parallel, such as state bleeding between tests, or port clashes.
17
20
18
-
Let's start from here, and see how to improve the test with Testcontainers:
21
+
Let's start from here, and see how to improve the test with Testcontainers:
19
22
20
23
## 1. Add Testcontainers as a test-scoped dependency
21
24
22
25
First, add Testcontainers as a dependency as follows:
The `@Rule` annotation tells JUnit to notify this field about various events in the test lifecycle.
47
-
In this case, our rule object is a Testcontainers `GenericContainer`, configured to use a specific Redis image from Docker Hub, and configured to expose a port.
57
+
Wrap the containers with `new TestContainersRule(...)` so the containers start and stop, according to the test lifecycle.
58
+
In this case, our rule object is not `static`, so the container will start and stop with every test.
59
+
The test configures `GenericContainer` to use a specific Redis image from Docker Hub, and to expose a port.
48
60
49
61
If we run our test as-is, then regardless of the actual test outcome, we'll see logs showing us that Testcontainers:
50
62
@@ -66,9 +78,9 @@ We can do this in our test `setUp` method, to set up our component under test:
66
78
<!--/codeinclude-->
67
79
68
80
!!! tip
69
-
Notice that we also ask Testcontainers for the container's actual address with `redis.getHost();`,
81
+
Notice that we also ask Testcontainers for the container's actual address with `redis.getHost();`,
70
82
rather than hard-coding `localhost`. `localhost` may work in some environments but not others - for example it may
71
-
not work on your current or future CI environment. As such, **avoid hard-coding** the address, and use
83
+
not work on your current or future CI environment. As such, **avoid hard-coding** the address, and use
72
84
`getHost()` instead.
73
85
74
86
## 4. Run the tests!
@@ -80,4 +92,3 @@ Let's look at our complete test class to see how little we had to add to get up
0 commit comments