►
From YouTube: Integration Testing of Jakarta EE Applications with Docker and Testcontainers | J1 Live 2021
Description
Thanks to tools like Docker, spinning up a full-fledged database isn’t more difficult or time-consuming than using an in-memory database anymore. So why not run your integration tests on your local machine, inside an environment which resembles production as close as possible? Enter Testcontainers!
____
Jakarta EE gives developers a comprehensive set of vendor-neutral, open specifications that are used for developing modern, cloud native Java applications from the ground up. With Jakarta EE, technology developers and consumers can be confident they have the best technologies for developing cloud native, mission-critical applications. And they can build on decades of Java developer expertise to move existing workloads to the cloud.
Learn more: https://jakarta.ee/
Follow us on Twitter: https://twitter.com/home
Follow us on LinkedIn: https://www.linkedin.com/showcase/jakartaee/
Like us on Facebook: https://www.facebook.com/JakartaEE/
A
Good
good
evening,
everyone-
or
at
least
for
me
it's
the
evening,
I'm
right
now
in
turkey,
istanbul
and
here
at
six
o'clock
now,
and
I
was
told
that
I
should
directly
begin
once
I'm
in
the
zoom
session.
So
I
will
just
do
it.
I
will
arrange
a
little
bit
my
windows
here
and
then
get
started,
and
yes,
I'm
very
happy
to
be
here
at
the
jakarta.
A
One
virtual
conference
in
person.
Quadrant
would
also
be
cool,
but
virtual
conference
will
also
work
nicely.
I
think-
and
if
you
have
any
questions
during
the
talk,
feel
free
to
just
ask
them
directly
in
whatever
tool
you
are
in
and
I
will
try
to
answer
them
as
soon
as
they
are
arrived
to
me.
Yes,
and
then
we
can
try
to
keep
some
interactivity
open
if
possible.
If
this
is
something
what
you
desire
all
right.
A
So
the
title
of
my
talk
today
is
jakarta:
ie
integration,
testing
with
docker
and
test
containers,
so
we
will
look
at
some
patterns
and
techniques
and
also
tools
that
might
help
you
with
better
ways
of
integration,
testing,
jakarta
ee
applications,
so
my
name
is
kevin
whittek.
I'm
currently
a
software
engineer
at
atomic
jar.
Atomic
jar
is
a
new
company
that
was
funded
this
founded
this
year
and
it
is
basically
the
test
containers
company.
A
A
So
after
working
some
years
in
the
industry,
I
went
back
to
university
to
do
my
phd
in
the
area
of
blockchain
research
and
distributed
ledger
technology
yeah.
But
this
is
a
little
bit
instant
by
right
now
and
sometimes
I'm
actually
also
kind
of
a
pigeon
researcher.
So
with
my
wife
is
a
behavior
psychologist,
we
have
a
couple
of
academic
papers
on
pigeons
on
pigeon
perception
and
evidence
accumulation
interesting
stuff.
A
You
can
find
them
if
you,
google,
for
my
name
and
pigeon,
maybe
also
a
little
bit
doing
consulting
and
coaching,
but
not
that
much
anymore
and
yeah.
I'm
here
also
in
my
role
as
one
of
the
test
containers
maintainers
and
in
general,
I'm
a
I'm,
a
big
fan
of
open
source,
the
open
source
community
in
general
and,
of
course,
the
open
source
java
community,
in
particular
I'm
oracle,
groundbreaker
ambassador
and
I'm
also
a
linkedin
learning
trainer
and
there
I
have
a
german
german
language
course
on
jakarta
e
basics.
A
A
You
should
be
able
to
just
check
out
the
repository
and
then
build
it
with
a
build
tool
of
your
choice,
made
more
gradle
and
that's
all,
then
that's
all
that
should
be
required
from
you
as
a
manual
step
to
be
ready
to
contribute
into
this
project
afterwards
by
running
this
command.
It
should
build
your
project.
It
should
run
your
unit
test.
It
should
run
your
integration
test
and
there's
nothing
manual.
You
should
do
ideally
yeah,
so
I
think
nowadays
in
the
industry.
A
It
should
look
like
this,
but
very
often
if
you
join
a
new
team
or
a
new
project,
it
looks
more
like
this,
so
you
will
be
pointed
towards
some
wikipedia
page
in
the
internet,
wiki
and
so
on,
some
confluence
page
and
you
will
have
some
longer
written
instructions
that
you
have
to
follow.
Okay,
you
have
to
install
this
application
server.
You
have
to
configure
it
like
this.
You
have
to
install
this
database,
you
have
to
load.
This
database
schema
et
cetera
a
couple
of
manual
steps,
sometimes
combined
with
some
scripting.
A
Maybe
that
sort
of
automates
some
things
and
half
the
things
are
broken.
Then
you
will
ask
someone,
they
will
say:
oh
yes,
of
course
the
wiki
is
not
up
to
date,
anymore.
What
you
have
to
do
is
this,
and
this,
and
this
and
yeah
that
is
not
really
an
enjoyable
experience.
It's
also
not
a
professional
experience
and
especially
if
we
consider
open
source
projects
that
makes
it
very
hard
for
for
newcomers
or
people
that
just
want
to
contribute
a
small
patch
to
actually
jump
in,
contribute,
something
quickly,
a
pull
request
and
then
jump
out
again.
A
So
that's
not
what
we
want
anymore,
and
what
can
we
use
in
the
java
world
to
yeah?
Go
a
bit
away
from
this
and
more
towards
this
complete
automation
where
everything
is
described
as
part
of
the
responsory
repository.
So
we
can
look
in
the
infrastructure
into
the
linux
world
to
the
docker
world
and
use
the
tooling
they
have
there
available
so
mostly
docker
and
container
technology.
A
This
can
help
you
can
help
us
a
lot,
because
it's
a
great
standardized
way
to
automate
certain
things,
certain
infrastructure,
like
components
or
certain
applications
that
are
not
our
java
applications
and
therefore
we
want
to
look
at
integrating
docker
with
our
java
code
more
or
less
and
the
best
way
in
my
opinion,
but
of
course,
I'm
obviously
biased.
The
best
way
to
integrate
java
code
with
with
docker,
especially
in
the
context
of
testing,
is
nowadays
probably
test
containers
the
test,
containers,
open
source
library,
and
we
will
look
at
this
library
today.
A
Okay,
so
I
said
I
want
to
the
I
want
to
have
a
good
development
experience.
It
should
be
checking
out
and
directly
being
able
to
develop,
but
now
I'm
bringing
a
testing
library
in
there.
Why
is
this
so
so
this
is
has
to
do
with
how
I
think
about
testing
and
if,
if
we
would
now
see
each
other-
and
I
would
sit
with
you
in
a
room,
I
would
ask
you
why
I,
why
are
you
testing?
Yes,
why
do
you
test
your
application?
A
If
you
test
it,
if
you
even
test
your
application
and
then
the
answers
could
be
different,
so
some
will
say:
okay,
I'm
testing
to
find
the
box
or
I'm
testing
so
that
in
the
future
I
won't
introduce
new
bugs
as
progressions,
and
then
there
are
others
that
just
say.
Okay,
I
have
to
write
tests
because
the
boss
said
I
have
to
write
tests.
The
boss
said
we
have
to
have
80
code
coverage,
so
I'm
just
like
writing
tests
that
go
through
all
branches
of
my
code.
A
A
I
really
really
love
writing
tests
and
testing,
because
for
me
it's
really
the
best
and
most
productive
and
most
enjoyable
way
to
get
early
and
constant
feedback
about
my
code
about
the
code.
I'm
writing.
While
I'm
developing-
and
I
felt
like
this
since
many
years.
Actually,
since
I
discovered
tdd
in
university
and
especially
td,
with
unit
testing
but
the
further
I
went
in
my
career,
the
more
I
thought:
okay,
like
this
unit
testing
and
doing
a
lot
of
mocking,
etc.
That's
not
always
the
best
way.
A
There
should
be
something
else,
and
maybe
real
integration
tests,
whatever
integration
tests
are,
could
be
more
advantageous
and
there's
a
lot
of
mocking,
etc.
So
that's
why
I
tell
you
about
testing
and
test
containers
and
testing
libraries,
not
only
to
make
you
give
you
a
better
role
as
a
tester,
but
also
to
make
you
as
a
developer,
more
productive
and
use
testing
as
a
tool
for
your
development
lifecycle.
A
A
It's
the
pyramid
of
the
sun
in
vijayoko
in
bosnia,
and
there
is
a
lot
of
discussion
about
this
construct
if
it
is
a
pyramid,
if
it's
just
a
hill,
if
it
has
been
constructed
by
humans,
if
it's
a
hill
that
has
been
shaped
by
humans,
to
look
more
like
a
pyramid-
and
it's
really
interesting,
I
recommend
just
read
the
wikipedia
article
about
this.
It's
also
not
really
serious
science.
A
What
is
done
about
this,
but
something
I
found
very
interesting-
was
certain
egyptian
egyptian
pyramid
experts
permit
researchers,
these
professors
they
were
pulled
into
and
they
had
to
comment
on
this
pyramid
and
they
said
like
okay.
What
do
you
think?
Is
it
a
pyramid?
And
yes
not-
and
they
said
like?
Oh,
it
doesn't
matter
if
it's
made
by
humans
or
not
as
long
as
the
shape
is
a
pyramid,
it's
a
geographical
shape,
a
geometrical
shape.
It
is
a
pyramid.
A
Uh-Huh,
okay,
so
very
interesting
definition
in
this
case
pyramid
like
if
a
hill
becomes
a
pyramid,
it
can
also
be
a
pyramid
and
if
we
think
about
testing
permits,
we
might
also
turn
it
around.
Maybe
the
important
thing
about
testing
pyramid
is
the
other
way
around,
not
that
it
looks
like
a
pyramid,
but
what
it
represents.
Okay,
yes,
very
far-fetched,
but
we
will
look
into
what
this
means.
A
So
you
will
probably
probably
know
this
classic
pyramid-
and
this
has
been
around
to
my
knowledge
in
the
software
industry
coming
out
from
the
agile
community,
mostly
around
people
like
my
cohn
in
the
early
2000s,
and
this
pyramid
advocates
for
a
test
use.
It
looks
like
this
with
a
lot
of
automated
unit
tests
that
are
the
foundation,
and
then
you
have
in
the
middle
less
integration
test,
and
then
you
have
even
lesser
end-to-end
tests
or
some
of
the
are
called
ui
tests.
A
Then
you
have
to
manually
explore
the
tests
on
top
of
it,
and
then
people
like
martin
fowler
would
say.
Okay,
actually,
we
have
an
axis
the
y-axis
and
the
y-axis
from
bottom
to
top
means
things
become
more
expensive
to
write
and
more
expensive
to
execute
and
slower
to
execute,
and
that's
why
this
pyramid
is
an
optimization.
So
this
permit
ship
is
an
optimization.
A
So
like
this
testing
honeycomb,
for
example,
spotify
advocates
for
this-
and
they
say
the
test
suits
of
their
of
their
microservices-
have
roughly
this
shape
and
they
also
give
the
levels
different
names,
so
the
bottom
implementation
details.
These
are
the
classical
unit
tests
that
look
very
deep
into
the
code
are
very
strongly
connected
with
it.
Then
they
have
a
lot
of
integration
tests,
they
say,
and
then
they
have
some
integrated
tests.
Integrated
tests
are
kind
of
an
anti-pattern
and
they
define
those
tests
as
those
that
fail
based
on
behavior
outside
of
their
control.
A
So,
for
example,
if
the
test
environment
changes
in
a
certain
way
and
so
on,
and
they
want
to
minimize
those
yes,
because
it's
not
nice
to
have
tests
that
will
fail
outside
of
your
control.
So
you
make
a
change
in
your
code.
Tests
fail
and
then
you
don't
know.
Okay
did
my
code,
make
the
failure
or
did
something
in
the
environment
change
and
therefore
it
failed
now.
So
those
are
not
good.
They
give
you
a
lot
of
insecurities
in
your
test
tube,
so
they
advocate
for
integration
tests
for
which
they
use
test
containers.
A
Yes,
that
allow
them
to
get
a
very
defined
state
and
very
defined
environment
infrastructure
as
code-like
approaches,
and
then
they
say
it's
great
to
have
many
integration
tests
because
they
allow
you
to
make
extreme
refactorings
of
your
services
of
the
inside
components
in
your
services,
especially
when
they
do
integration
tests
from
outside
from
the
outside
public
apis.
They
can
throw
away
whole
micro
services
put
new
in
there
and
have
still
the
same
test
tune.
A
So
then
it
makes
sense
that
also
in
the
test
suit
the
relation
the
ratio,
changes
and
you
get
more
integration
tests,
because
you
have
a
higher
integration
surface
and
you
are
doing
a
lot
of
assembly
in
microservice
architectures,
where
you
want
to
yeah,
assemble
different
components,
different
micro
sources
or
different
products,
databases,
and
so
on
and
check
the
interaction
with
them.
Rather
than
writing
a
lot
business
code
yourself,
okay
and.
A
Then,
last
but
not
least,
this
is
a
shape
that
comes
from
the
javascript
community,
mostly
to
my
knowledge,
so
ken
dodge
posted
this
or
tweeted
this
and
the
honeycomb
like
shape,
is
still
the
same.
I
would
say,
but
what
I
found
very
cute
is
that
he
had
this
block
the
static
block
at
the
bottom,
and
they
say
these
are
kind
of
tests
that
that
a
static
language
and
type
system
brings
to
you
so
because
of
having
having
a
statically
compiled
language
and
type
system.
A
Certain
classes
of
failure
can't
happen,
so
these
are
implicit
tests
if
the
compiler,
the
compiler,
does
it
for
you
and
it's
a
nice
way
to
think
about
it.
I
think
proponents
from
dynamic
languages
would
argue
differently
and
they
would
say:
okay,
maybe
those
kind
of
bottoms
of
static
tests
that
that
come
out
of
the
compiler.
They
don't
capture
the
important
classes
of
bugs
here,
but
still
it's
it's
a
nice
way
to
think
about
this.
A
It's
even
hard
to
classify
them
in
those
two-dimensional
shapes
where
we
have
okay,
these
are
unit
tests
and
then
some
way
going
to
the
y-axis
they
become
heavier
or
whatever,
and
then
they
become
suddenly
integration
tests
based
on
some
kind
of
property,
so
that
might
not
really
really
capture
the
nature
of
tests
really
well.
So
there
seem
to
be
at
least
three
dimensions
I
would
identify
and
yeah.
A
A
A
Testing
against
this
running
application
feels
for
me
very
much
like
an
integration
test
or
when
I'm
testing
interactions
with
bigger
subsystems
like
the
subsystems
that
that
a
jakarta
application
server
would
bring
like
the
jpa
or
whatever
yeah.
That's
very
integration,
testy
and
especially
then.
Those
classic
examples
like
interactions
with
outside
external
process,
like
the
database
that
is
running
as
its
own
program
calls.
I
have
to
do
over
the
network
or
interactions
with
the
file
system,
also
very
integration
test,
integration,
testing,
okay,
but
yeah.
A
I
found
very
interesting
ways
that,
like
he's
here
in
his
opinion,
a
unit
test,
it's
if
a
unit
test
can
talk
to
external
resources,
and
this
is
fast
and
stable
enough.
It's
fine
and
you
can
still
call
it
a
unit
test.
You
know-
and
now
I
would
argue,
with
tools
like
like
docker
and
then
tesla
has
to
instrument
them.
We
can
maybe
because
we
can
start
containers
in
a
fast,
reliable
way.
We
can
just
use
the
containers
as
part
of
our
unit
test
and
still
call
the
unit
test,
not
integration
tests.
A
A
If
you
say
you're
already
using
test
containers
or
you
wanted
to
use
it
and
you
can't
use
it
for
some
kind
of
constraints
you
have
in
your
company
or
in
your
application.
I
would
also
be
very
interested
to
learn
about
this,
and
maybe,
after
the
talk
discuss
with
you,
how
you
can
maybe
integrate
it
better
with
your
use
cases.
A
So,
let's
look
at
test
containers,
the
java
library
and
the
api,
the
vanilla-like
api.
We
can
use
it.
So
it's
an
object-oriented
abstraction
over
docker
containers
and,
as
you
can
see,
we
can
just
instantiate
java
objects
that
represent
the
containers
and
then
we
can
instrument
them
just
as
you
would
expect.
So
you
can
start
them.
You
can
stop
them.
A
A
The
starting
is
very
important
that
the
starting
will
not
only
start
the
container,
but
it
will
also
wait
and
assert
a
ready
state
of
the
application
inside
the
container.
This
is
very
useful
because
starting
a
container
means
starting
a
process
starting
a
process
is
a
very
different
thing
of
an
application
being
ready
and
being
ready
to
be
used
in
your
test.
Yes,
just
think
about
the
postgres
database.
A
A
But
I
must
honestly
say
you
should
really
consider
when
this
is
useful
and
when
this
is
not
useful,
because
starting
and
stopping
containers
for
each
tests
or
sometimes
even
for
each
test
class
tends
to
be
very
expensive
still.
So
it's
much
better
to
start
containers
once
for
the
old
tests.
You
run
all
your
tests
and
then
tear
everything
down,
and
we
will
also
look
in
the
live
example
how
to
do
it?
The
question
about
our
queen.
A
I
will
answer
in
a
following
slide,
at
least
to
my
best
of
my
knowledge,
because
I'm
not
an
aquarian
expert,
but
I
will
tell
a
little
bit
about
it.
Okay,
a
bit
more
about
test
containers,
so
test
containers
java
has
been
released
in
2015..
It's
400
percent
open
source
under
mit
license,
so
everything
is
mit
licensed
or
everything
is
open
source
in
test
containers.
Some
third-party
modules
that
are
not
in
our
core
repo
can
somehow
be
on
a
different
license,
of
course,
like
apache
license
or
whatever,
but
test
containers
java
completely
mit
licensed.
A
A
Now
I'm
working
there
as
an
engineer,
and
we
also
have
test
containers
forks
in
other
languages
with
different
degrees
of
maturity,
but
if
you're
in
another
language,
you
can
also
check
it
out.
Probably
most
of
you
here
are
java
developers,
so
yeah,
okay
and
yeah.
Let
me
try
to
quickly
summarize
some
of
the
features,
so
we
have
support
for
different
kind
of
modules
specialized
support.
Then
you
don't
have
to
use
this
generic
container
interface,
where
you
just
specify
a
docker
image.
No.
A
Instead
we
have
special
classes
that
are
already
optimally
configured
to
run
a
certain
container
like
the
postgres
or
kafka,
or
something
like
selenium.
Yes
and
those
kind
of
things
we
have.
You
can
find
them
all
on
our
website.
Testcontainers.Org
selenium
is
very
interesting
with
the
browser
running
inside
the
container.
In
this
case
and
yeah,
you
can
also
use
docker
compose
if
you
already
have
docker
compose
files
available,
but
generally
committing
to
test
containers
is
a
bit
more
powerful.
I
would
say
inflexible,
yes
and
so
dynamic
building.
A
And
then
a
nice
thing,
it
works
really
on
all
environments,
all
major
environments,
so
docker
for
windows,
docker
for
mac,
the
classic
docker
on
linux,
but
also
setups,
like
docker
machine
or
having
a
docker
host
environment
variable
set
with
a
remote
docker
demon
test
containers
will
work
out
of
the
box
with
those
things
and
yeah
directly
discover
the
environment
and
configure
itself.
So
you
have
to
do
nothing
just
at
the
maven
depends
and
then
you're
good
to
go.
A
A
Of
course,
we
have
something
like
j-unit
and
j-unit.
Besides,
the
name
can
of
course
be
used
for
more
than
a
unit
test
or
classical
unit
test,
but
just
for
defining
and
executing
tests
all
kind
of
tests.
So
we
will
also
go
on
using
this.
Yes,
we
have
a
billion
and
I'm
not
one
person
an
expert
about
the
current
state
of
aquarium.
A
So
back
then,
I
know
there
were
some
problems
that
it
was
not
compatible
with
jupiter,
etc,
not
sure
how
the
maintenance
status
of
it
is
right
now,
and
the
main
difference
is
that,
as
far
as
I
know,
acrylic
has
one
mode
where
you
are
doing
in
process
testing
so
where
equilibrium
can
inject
beans
and
so
on
into
your
test
classes.
And
then
you
can
interact
with
them
directly
like
what
we
know
from
the
spring
boot
testing
framework,
for
example,
so
test
containers
won't
do
this
test.
A
Containers
is
always
out
of
process
but,
as
I
know,
a
queen
also
has
an
out
of
process
test
mode,
so
probably
test
containers
a
bit
similar
and
maybe
in
some
ways
cleaner.
But
I
can't
comment
one
hundred
percent
because
I
don't
know
enough
about
acrylic
painting
and
some
of
you
might
have
heard
about
microsoft,
microsoft,
testing
migration
testing
actually
uses
test
containers
underneath
to
spin
up
the
jakarta
or
java
ee
application
servers
in
docker
containers.
A
So
it's
completely
test
containers
based
and
then
it
generates
those
proxy
classes
for
you
to
interact
with
your
rest
controllers
or
whatever,
and
it's
also
a
cool
project.
But
I
would
recommend
that
you
first
learn
and
understand
the
flexibility
and
the
capabilities
of
test
containers
before
you
decide
to
use
microsoft,
because
microsoft
also
has
certain
limitations
and
yeah.
What
we
will
look
at
today
is
a
test
container
based
a
test
setup.
A
I
would
say-
and
then
this
is
a
combination
of
j-units,
of
test
containers
and
rest
assured
as
a
as
a
way
as
a
rest,
client
and
asserting
the
responses
of
the
server
basically,
and
we
will
look
at
a
setup.
That
is
something
like
this,
so
it
will
be
an
out
of
process
test
in
the
form
of
a
opaque
box
here
so
close
box
principle.
So
we
will
have
our
jvm
process.
A
We
will
have
our
junit
test
and
the
junit
test
will
use
just
normal
java
code
to
instrument
test
containers
to
create
our
environment,
set
up
the
containers
we
need
and
we
will
need
a
cuttery
application
and
a
postgres
database
and
then
test
containers
we'll
use
the
docker
api
to
talk
with
some
kind
of
docker
demon,
which
I
didn't
show
here
now.
So
it
will
use
docker
basically
to
to
spin
up
those
containers
and
configure
them
in
a
way
and
they
will
be
connected
in
the
same
docker
network
so
that
they
can
see
each
other.
A
A
So
I'm
having
a
very
naive
example
application
here,
but
we
we
will
be
able
to
see
the
general
gist
of
everything
I'm
having
maven
and
if
you
want
to
use
test
containers.
So
all
you
have
to
do
is
add
the
maven
dependency
or
gradle
dependency
and
we
have
a
bill
of
materials
just
like
jm
jupiter
has
so
I
added
the
bill
of
materials
and
then
for
the
individual
dependencies.
A
I
can
leave
out
the
version,
but
you
don't
have
to
use
it
like
this
and
yeah,
we'll
use
jupiter
rest
to
shoot,
and
then
here
we
can
see.
These
are
the
different
modules
we
want
to
use
the
different
test:
containers
modules,
postgres
module
and
the
junit
jupiter
module
all
right,
and
then
the
application
is
a
jakarta
ee
application,
and
so
we
we
have
a
couple
of
services
there
that
don't
do
anything
particularly
interesting.
A
A
But
just
that
you
see
all
the
parts
together,
so
we
have
a
book
class
and
then
we
have
a
book
repository
that
uses
a
jpa
to
interact
with
a
data
source
to
yeah,
to
save
those
entities
in
a
relational
database,
and
the
controller
exposes
us
accordingly
and
then
we
have
a
couple
of
of
other
endpoints
that
don't
do
anything
particularly
interesting,
so
touring
controller,
for
example,
just
gives
you
the
touring
award
winners
of
a
certain
year
and
it
uses
an
in
memory
data
structure.
So
nothing
especially
interesting
on
the
jakarta
application
side.
A
So
let's
look
now
at
the
test,
all
right,
so
the
top
here
are
the
the
test
containers
specific
classes,
I'm
now
using
the
junit
jupiter
test
framework
integration
of
test
containers,
just
as
an
example,
you
don't
have
to
do
it
like
this,
but
just
as
an
example
here,
then
I
annotate
my
class
like
this.
With
that
test
containers.
A
Now
I
say
I
want
to
have
a
network.
This
will
become
a
docker
network
and
I
say
I
want
to
have
a
postgres
container,
so
I'm
specifying
the
special
postgres
container
class
here,
which
is
a
test
containers
module.
I'm
saying
okay,
please
put
this
container
onto
the
network
and
give
it
a
network
alias
postgres.
Then
docker
will
play
dns
for
me,
and
other
containers
that
are
in
the
same
network
can
resolve
this
container
via
this
dns
name
very
convenient.
I
annotate
these
classes
at
containers.
This
means
junit,
jupiter
extension.
Please
measure
this
container
lifecycle.
A
For
me,
I
put
it
as
a
static
field.
Static
field
means
the
life
cycle
of
this
container
is
the
lifecycle
of
the
test
class.
Then
now
the
jakarta
application,
which
is
more
interesting
now
I'm
using
a
generic
container
class,
I'm
specifying
a
docker
image
as
a
docker
image.
I
take
payara
micro
just
to
have
something
small
that
starts
quickly.
A
That
is
now
a
very
easy
way
to
do
it.
It's
important
to
use
copy
file
to
container
and
not
mount
file
to
container
in
test
containers,
because
the
mounting
a
file
can
be
problematic
in
certain
cr
environments.
When
you
have
docker
in
docker
situations
et
cetera
copying,
the
file
will
always
work,
and
so
this
will
work
nicely.
A
But
of
course
you
could
also
consider
throwing
your
own
custom
image
in
here.
So
maybe
you're
already
building
docker
images
that
have
your
deployed
exploded
war
file
in
there
yes
and
just
specify
this,
then
you
don't
need
to
copy
this
okay
now
this
is
quite
important.
This
is
now
configuring
the
waste
strategy
for
my
jakarta,
ieee
application-
and
I
can
say:
okay
when
the
container
locks
payara
ready
in
and
then
there
are
some
dates
like
in
how
many
seconds
and
so
on.
A
A
So
if
you
have
a
jakarta
e
application
and-
and
you
use
a
configuration
mechanism
that
allows
you
to
configure
certain
properties
with
environment
variables,
use
this
because
it
gives
you
so
much
more
flexibility
and
in
this
case
I'm
using
I'm
configuring
the
database
connection
specific
things
using
environment
variables,
because
I'm
using
this
data
source
definition,
annotation
and
my
jakarta
class,
and
then
I
are
using
this
callouts
here
with
n.
So
since
I'm
not
the
super
duper
jakarta
expert,
I
don't
know
if
all
jakarta
application
server
supports
this.
A
A
Okay.
I
know
it
will
be
in
this
case.
It
will
be
test
test
because
I
just
know
it.
Postgres
container
has
those
values,
but
I
could
also
say
wait.
I
could
say
here
with
database
name
and
password.
If
I
want
to
customize
it,
I
could
do
so,
which
I'm
not
doing
you
know,
and
I
can
now
even
hard
code,
the
jdbc
url,
because
they
are
connected
in
this
own
docker
network
and
then
I
will
know
it
will
be
reachable
there.
A
A
8080
on
a
report
dynamically
using
the
publish
port
feature
from
docker
and
then
through
this
method,
we
are
able
to
get
the
actual
map
port,
which
will
be
something
like
60
000,
something
whatever
okay
and
then
we
have
the
url
at
which
we
can
interact
with
our
jakarta
application
and
yeah.
Now
we
see
here
a
couple
of
rest
assured
tests
and
yeah.
This
is
a
test
that
just
checks,
status,
code,
200
more
or
less
at
a
certain
end
point
is
a
touring
endpoint
and
here
some
database
interaction.
A
Where
I
check
okay,
I
can
list
the
books
and
I
can
save
a
book
and
then,
if
I
check
the
list
again,
it
has
increased
by
one
more
or
less.
So
let
me
run
this
now.
There
was
a
question
if
I
can
share
the
demo
on
github.
Yes,
I
can.
I
will
I
have
already
done
so.
I
will
show
this
in
a
bit,
so
it's
already,
if
you
check
my
github
account,
should
be
there.
So
we
see
the
application.
Now
the
tests
are
running.
A
Here's
some
logs
from
docker
I'm
connected
to
test
containers
cloud
right
now,
it's
just
it's
a
new
product
from
atomic
jar.
It's
just
an
alternative
to
running
things
with
my
local
docker
agent,
but
I
could
also
use
my
my
local
docker
dean
with
docker
desktop
on
windows.
No
problem
would
work
the
same,
I'm
just
using
now
a
cloud
docker
demon
with
test
containers
cloud
to
reduce
the
load
on
my
my
machine
here
and
also
since
I
don't
have
the
fastest
internet.
When
I'm
using
the
cloud
docker
daemon
pulling.
The
images
is
much
more
much
faster.
A
A
A
Okay,
that's
that's
all
there
is
to
it
actually
here
so
I
didn't
have
to
install
postgres.
I
didn't
have
to
install
or
configure
payara
here
by
myself
and
any
one
of
you
that
will
check
out
this
repository
on
github
and
you
will
just
be
able
to
run
maven
verify
and
if
you
have
docker
available,
it
should
ideally
run
the
test.
The
same
way
without
any
manual
setup
necessary
all
right.
Okay,
I'm
basically
out
of
time.
So
there
is
now
the
remaining
time
for
questions.
A
So
here
we
saw
usage
with
the
test
containers
extension
there's
another
way
which
we
like
very
much,
and
here
I
can
actually
remove
those
annotations.
We
call
it
singleton
container
pattern,
and
here
we
like
to
have,
for
example,
an
abstract
class
like
abstract
integration,
test
class
that
will
define
all
those
containers
like
the
container
setup.
Basically
and
then
we
start
the
containers
in
the
static
initializer
block
like
one
time
and
that's
it,
and
then
you
can
in
all
classes
that
need
to
interact
with
your
system.
A
You
can
just
extend
this
abstract
class
and
then
just
directly
interact
with
them.
Then
you
don't
have
to
duplicate
the
setup
of
containers
and
you
can
reuse
the
same
environment,
the
same
containers
for
all
your
tests.
So
basically
what
this
does
is
binds
the
life
cycle
of
the
containers
to
the
life
cycle
of
your
jpm
or
the
life
cycle
of
your
test,
huge
so
to
say,
and
if
you
look
closely
I'm
starting
the
container
here,
I
never
stop
them.
Is
this
okay?
A
Yes,
this
is
okay,
because
test
containers
as
a
default
will
always
clean
up
all
its
resources
on
jvm
exit.
So
you
don't
have
to
take
care
of
closing
or
removing
the
containers.
Removing
the
images
test
container
has
some
very
nice
sophisticated
mechanisms
to
clean
up
everything
and
that
works
nicely
on
your
local
machines,
as
well
as
on
ci
machines,
so
that
you
don't
end
up
with
a
lot
of
zombie
containers
anyway,
all
right!
Okay,
thank
you.
That's
the
end
of
the
demo.
A
A
If
this
is
the
case,
then
I
would
say
like
the
the
product
we
are
developing
and
atomic
test
containers
cloud
is
one
of
the
answers
for
this,
because
we
lift
the
container
workload
away
from
the
machine
into
the
cloud
to
run
it
for
you,
and
then
you
have
just
the
tests
itself
the
test
process
running
and
interacting
with
them
yeah,
but
it
depends
so
the
abstraction
itself
is
a
bit
too
leaky.
I
know
people
always
think
they
can
apply
the
same
abstraction
as
test
containers.
A
Vernitas
or
also
on
things
like
portman
and
so
on
and
in
theory,
you
can
but
the
edge
cases
are
problematic
and
they
are
so
problematic
that
the
abstraction
as
it
works
right
now,
would
not
directly
work
because
we
are
very
docker
opinionated.
With
the
current
test
containers
implementation,
I
would
say.
A
A
A
Yes
here
it
is,
and
it's
already
public.
So
that's
it
test,
containers
jakarta
demo
and
this
should
work
as
is
and
yep
any
more
questions
shoot
me
a
message
on
twitter
and
you
can
check
out
the
test.
Containers,
documentation,
discontents,
org
and
yes
have
fun,
and
I
would
be
very
interested
if
you,
if
you
share
with
me
your
experiences
of
using
test
containers
together
with
jakarta
e
and
your
jakarta,
ie
use
cases
and
applications.