►
From YouTube: Why Kubernetes Applications Require a New Approach to Testing using Testkube - Bruno Lopes, Kubeshop
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
Why Kubernetes Applications Require a New Approach to Testing using Testkube - Bruno Lopes, Kubeshop
Microservices, CI/CD, DevOps, GitOps, cluster networking, etc… — more and more teams are building software fundamentally differently than they did even a few years ago. However, testing approaches and tooling have not caught up yet. At least not until now. What if you could apply the same type of GitOps and DevOps methodologies to your testing activities ? Tests could be deployed and stored in a Kubernetes cluster, they could decoupled from your CI/CD, orchestrated in the cluster in the same way you do with your applications and not in your CI/CD, publish results aggregated in a common format and triggered with a simple API request. Looks promising right ?
Let’s have a look at Testkube, an open-source framework that is moving to be the cloud-native testing framework for all your Tests in Kubernetes. Whether you are using Postman, Cypress, K6, SoapUI, or any other testing tool, Testkube can unlock all the capabilities of those tools that allow you to deliver code with confidence.
A
Before
you
start
just
a
little
bit
about
myself,
so
I'm
Bruno
Lopez
yeah,
can
you
hear
me
fine
at
the
end?
Can
you
hear
me
guys?
Fine,
oh
okay,
oh
nice,
so
yeah
my
background
is
in
software
engineering
devops
as
well,
and
for
the
past
year,
I'm
leading
these
cool
product
called
test
Cube
that
we
are
going
to
talk
about.
A
A
Okay,
all
right
cool,
so
you
might
relate
to
some
of
these
challenges.
We
are
going
to
talk
about
today,
so
I'm
just
gonna
list
a
few.
So
the
if
you
use
different
tests
in
kubernetes,
you
might
use
different
tools
depending
on
the
type
of
test
you
might
test
apis
uis
and
do
a
bunch
of
things
and
one
of
the
big
problems
with
those
tools.
They
are
not
made
from
the
ground
app
to
run
inside
the
kubernetes
cluster.
A
They
are
not
made
with
kubernetes
in
mind,
for
example,
to
give
an
example
of
a
few
testing
tools.
Q6
is
a
really
great
tool
for
load
testing.
Soap.
Ui
for
API
testing
is
a
really
gold
old
one
Cyprus
for
UI
Postman.
Those
are
very
good
and
they
are
very
good
at
use
guys.
So,
for
example,
if
you
want
to
load
testing
use
cases
for
load
testing,
but
they
were
not
made
exactly
to
run
in
kubernetes
right
away,
they
give
you
they
help.
A
They
give
you
documentation,
they
might
give
you
Docker
images
on
that
on
Docker,
app
that
they
can
use
to
use
it
as
a
test
runner
on
your
cluster.
But
you
cannot
just
take
a
test
in
JavaScript
and
run
it
in
your
class
right
away.
You
need
to
do
some
stuff
and
if
especially,
if
you
want
to
automate
it
there's
some
steps
you
have
to
do.
A
A
Another
challenge
of
fossil
testing
in
kubernetes
is
that
it
might
it's
it's
kind
of
hard.
If
you
have
a
complex
structure,
there
have
many
micro
services
with
thousands
of
tests
or
analogs.
Each
testing
tool
has
different
different
log
output
and
they
are
running
different
pods
and
in
different
steps
of
the
pipeline
that
that
will
become
hard,
especially
as
you
scale
so,
and
if
you
want
to
see
the
history,
for
example,
you
have
a
test
that
fails
and
you
want
to
see
one
month
ago,
the
same
unlocks
from
that
might
be
difficult
to
do
that.
A
Another
thing
which
is
also
very
peculiar,
is
imagine
if
you
have
a
Cypress
test
for
for
those
of
you
that
don't
know,
Cypress
basically
allows
you
to
run
tests
in
the
browser.
So
if
you
have
an
UI,
you
can
just
basically
simulate
the
human
clicking
on
buttons
and
and
do
all
that
simulation
and
one
of
the
things
that
these
two
allows
is
to
produce
a
video
of
that
test.
A
For
example,
you
are
testing
your
UI
and
basically,
if
the
test
fails,
if
the
UI
is
broken,
you'll
be
able
to
see
a
video
of
it,
and
if
you
are
running
that
test
as
a
runner
in
kubernetes,
you
now
have
a
challenge,
which
is
how
do
I
get
that
test
artifact,
which
is
that
video?
How
do
I
save
it
and
I
have
like
I
track
it
with
the
test
execution
and
on
my
pipeline?
A
So
that's
also
another
challenge
that
you
you'll
have
to
basically
fix
which
is
otherwise
store,
although
I
get
Android
device
for
my
test
artifacts,
the
other
one
is
a
restricted
access
to
your
environments,
especially
in
big
carpets.
You
might
not
have
the
access
to
that
cluster
that
you
want
to
test
you.
You
are
in
charge
of
doing
those
tests
or
doing
the
code,
and
then
you
deploy
the
environment,
and
then
you
want
to
test,
but
you
don't
have
access
so
yeah.
So
that's
another
challenge
here.
A
So
with
that
in
mind,
the
challenge
is
mine.
This,
where
this
term
of
cloud
native
testing
comes
up,
which
is,
you
should
think
about
your
tests
or
your
testing
Solutions
in
a
way
that
we
are
Cloud
native,
and
you
don't
need
to
worry
about
so
much
about
all
these
challenges
should
be.
Should
your
test
should
be
able
to
scale?
You
should
not
have
really
long
pipelines
that
take
a
lot
of
time,
because
you
just
want
to
test
it.
A
For
example,
I
saw
people
that
have
like
really
hours
of
work
that
they
just
need
to
wait
because
the
pipelines
is
running
and
they
are
waiting
for
the
test
to
finish,
and
especially
now
in
the
alternative
era,
and
we
are
using
kubernetes,
things
should
be
paralyzed,
the
teachers
just
scale,
and
it
should
not
really
have.
You
know,
synchronous
things
that
you
need
to
wait
a
long
time
just
just
to
see
if
they
are
working.
Gathering.
A
Also,
that
you
should
have
in
mind
is
flexibility.
You
should
not
be
very
tight
to
any
cicd
system
in
particular
or
or
even
testing
tool,
or
it
should
not
block
you.
Your
your
pipeline
should
not
block
you
from
Tiny
tools
from
adding
more
tests
or
changing
things.
It
should
be
still
very
flexible
if
somebody
says
oh
I
really
found
this
new
tool
and
I
want
to
add
a
new
test
to
our
pipeline.
It
should
not
be
a
it
should
be.
A
A
Automation
is
things
is
something
that
you
know
should
should
kind
of
come
out
of
the
box.
You
should
not
really
worry
so
much
about
automation.
Things
should
just
be
easy
to
automate,
and
you
don't
usually
it
is.
It's
like
a
repetitive
work,
just
what
my
things
and
things
should
just
work.
So
that's,
basically,
the
the
third
pillar
of
cognitive
testing,
so
yeah
with
all
of
this
in
mind,
I
wanted
to
introduce
you,
our
our
open
source
project
called
test
Cube.
This
basically
tries
to
solve
all
of
these
challenges
that
you
just
saw.
A
So
we
are
the
kubernetes
native
testing
premise,
which
is
basically
tries
to
take
off
these
tools
and
combine
it
together,
their
open
source,
as
I
said
and
part
of
cncf,
and
you
really
focus
on
that
test.
Automation,
part
management
and
also
visualization
of
earlier
tested
run
in
the
kubernetes
cluster.
A
A
You
need
to
do
some
code
on
your
pipeline
whatever,
if
it's
GitHub
actions
Jenkins
whatever
it
is,
you'll
need
to
do
something
there
to
to
add
your
test
logic
there,
and
also
you
need
to
use
docker
images
or
any
sort
of
container
image.
If
you
want
your
test
to
run
inside
the
quantities
cluster,
because
everything
runs
inside
the
container
of
course,
so
we
also
need
to
provision
that
test
executor.
A
Yeah,
so
still
competing
restricted
environment.
We're
just
going
to
go
pass
to
this
because
I
talked
about
it
before
artifact
storage
scaling,
you
know
making
your
your
life
is.
If
you
are
a
tester,
you
should
focus
really
on
testing
on
to
on
writing.
The
test
should
know
what
what
microservice
to
write
or
which
things
you
are.
You
need
to
add
more
tests
off
and
should
not
worry
about,
basically,
the
manual
stuff
or
like
just
basically
technical
Parts.
There
are
these.
A
There
are
a
lot
of
patterns
across
many
projects
that
everybody
solves
them
in
a
custom
way,
and
there
are
tools
like
these
ones
that
can
just
make
it.
You
know
in
a
general
way,
can
can
solve
it
very
easy
for
you.
So
one
of
one
of
the
ways
you
can
Define
death
in
in
kubernetes
is
vscrds,
so
test
tube,
allows
you
to
just
Define
in
a
yaml
your
test
and
then
takes
the
care
of
them,
basically
defines
so
you
just
as
you
take
any
tool
these
ones
come
out
of
the
box.
A
A
Can
you
hear
me
yes,
so
here,
usually
you
have
more
steps
like
linters,
because
coding
analysis,
maybe
unit
tests
for
sure.
Then
you
deploy
to
an
environment.
This
is
an
example
of
one
environment.
Can
I
have
Mar,
and
then
you
have
different
steps
that
you
could
run
like
different
apis
tests.
Ui
tests
could
be
load,
you
know,
could
be
anything
security
whatever
you
mention
it.
So
if
you
want
to
add
more
steps
here
or
different
environments,
you
need
to
add
that
logic
to
your
pipeline.
A
In
the
example
here,
just
just
gonna
walk
here
and
show
you
can
basically
declare
your
test
the
CRTs.
So
this
is
a
kubernetes
cluster.
You
can
declare
them
here.
Test
cube
is
prepared
to
run
them
for
you.
So
as
you
declare
them,
they
they
become
part
of
your
cluster.
They
are,
they
are
part
of
that
state
and
your
pipe
becomes
very
like
it
becomes
very
simple
to
use.
You
don't
have
any
scripts
there
or
like
just
the
logic,
to
configure
things
you
just
one
of
your
steps
to
fail.
A
If
something
is
not
working,
you
can
just
say
for,
for
example,
test
Cube
run
my
test
or
my
test
suite,
and
your
pipeline
will
fail
if
you
wanted
to
and
but
everything
all
the
complexity
lives
here
and
not
here.
So
your
pipelines
don't
have
all
of
that
cumbersome
scripts
that
that
you
might
need
to
code.
A
A
This
is
a
q6
test
that
fails
off
of
the
times
so
that
so
just
those
load
tests
on
this
URL
and
after
half
of
the
times
you
you
run
it,
there's
a
random
here,
a
random
number
of
times
you'll
file
oftentimes.
It
will
pass
so
you
can
use
this
Cube
using
the
UI
or
the
CLI
I'm.
Just
gonna
do
the
UI
here,
because
it's
more
clear
to
you
to
understand
what's
happening
if
I
use
the
CLI
may
be
less
clear.
A
So
here
you
can
see
basically
all
the
tests
inside
your
cluster,
let's,
let's
go
to
this
flow
of
adding
one
test
and
then
I'm
gonna
go
through
through,
basically
all
the
rest.
So
let's
just
start
with
one
simple
test
right
now,
so
you
can
basically
create
a
test
in
your
cluster,
as
I
mentioned,
with.
Rtc
is
a
kubernetes
resource.
So
basically,
this
is
a
front
end
to
your
cluster.
A
So
here
you
basically
select
a
type
of
test.
You
are
want
to
run
so
all
the
the
tools
that
you
basically
configured
to
to
run
and
test
Cube
the
allows
Out
of
the
Box
menu
so
I'm
going
to
select
key
six
and
then
I'm
going
to
select
where's
the
test
source,
for
example.
If
you,
you
should
have
your
testing
it.
So,
for
example,
thank
you
yeah
much
better,
so
you
can
define
a
crd
in
your
cluster
that
fetches
the
test
data
and
the
test
content
from
your
GitHub
repo,
and
they
should
live
there.
A
So
I'm
doing
doing
this
manually,
I'm
creating
a
test
menu
for
your
cluster,
but
hopefully
in
automated
way,
ufts
running
on
your
repo.
So,
let's
just
for
the
purposeful
presentation,
I'm
going
to
just
upload
a
file
here
and
k6
test
random
is
the
the
debt
test.
I
just
showed
you
that
fails
after
times
and
I
just
defined
that
test
on
my
cluster
here
as
a
crd.
So
this
is
like
a
yaml.
This
is
a
CRF
type
test.
You
see
the
metadata
in
the
namespace.
A
You
have
labels
just
no
just
like
normal
kubernetes
resource
and
now,
like
the
crd,
is
defined
there.
A
test,
Cube
picks
it
up.
There's
the
operator
and
I'm
just
going
to
schedule
like
a
bunch
of
times.
I
know
26
should
be
enough
to
Nuke
the
server,
and
so
basically
now
they
are
running
in
parallel
as
kubernetes
shops,
and
basically
some
of
them
are
passing.
A
Some
of
them
are
failing,
so
basically
the
the
pods
now
so
what
has
given
us
schedule
the
shops
it
tracks,
what
he's
doing
and
and
see
like
if
the
port,
the
test
failed
or
the
job
failed,
it
will
Mark
the
test
has
failed
or
if
it
passed,
the
Mark
has
passed
and
also
fetches
the
logs
from
that
executor
and
the
the
so
you
can
see
the
logs
of
what
happened
there
yeah.
So
so
that's
that's
mainly
what
you
do
when
you
are
trying
from
a
test.
You
can
quickly
like
come
here.
A
A
So
it
gives
you
that
that
high
level,
View
and
also
metrics,
so
one
thing
I
was
not
I
was
forgetting
to
mention-
is
that
you
also
want
to
have
metrics
about
your
test.
If
you
have
a
cluster
and
applications
here,
and
you
are
developing
developing
that
for
one
year
or
more
now,
knowing
if,
if
your
test,
no
fail
a
lot
or
pass
a
lot,
also
very
interesting
for
you.
A
So
just
just
a
quick
summary
of
what
you
can
do
here
basically
have
test
test
Suites
one
thing
also
that
just
got
released
like
a
few
days
ago,
so
I'm
not
going
doing
a
demo
right
now,
because
I
didn't
prepare
it,
but
I
I,
just
wanted
to
show
you
as
well
is
I
showed
you
an
example
of.
Oh
a
pipeline
can
trigger
tests,
but
imagine
that
you
have
your
pipeline
just
deploying
your
application
and
then
test.
A
Cube
knows
when
to
run
your
test,
so
in
this
example
desk
you
could
listen
to
resources
on
your
cluster,
for
example,
you
could
listen
to
a
pod
when
a
pod
with
a
certain
label
is
modified.
You
can
tell
test
Cube
to
run
any
type
of
test
that
you're
defining
there.
So
basically
your
tests
are
like
you
can
just
make
the
list
of
which
events
or
cluster
events
you
want
to
listen
and
then
the
test
Cube
will
run
this
test
for
you.
A
So
you
don't
even
need
to
add
any
step
on
that
pipeline,
because
now
this
is
intelligent
enough
to
see.
Okay,
this
event
changed.
Let
me
run
the
test
and,
for
example,
if
you
want
then
a
message
on
slack
or
anything,
you
can
just
Implement
web
books
here
and
then
it
will
just
send
those
messages,
so
so
yeah.
So
that's
that's
basically
it.
A
A
Exactly
yes,
yes,
so
basically
the
E3
and
also
the
The
Matrix,
and
also
like
we
can
have
time
frames
and
and
yeah
and
all
that
something
so,
for
example,
if
you
want
to
parameterize
your
test,
you
can
also
pass
environment
variables,
so
you
have
like
secrets,
you
can
yeah
and
and
then
they
get
mounted
on
your
bot
as
environment
variables.
And
then
then
you
can
pick
that
up
as
well.
A
A
A
Can
you
you
can
schedule
the
test?
You
can
have
crown
jobs,
so
it's
not
in
the
uis,
it's
like
it's
for
maybe
in
two
releases
but
using
the
the
terminal.
So
let
me
just
show
you,
like
you
can
just
say:
desk
Cube
creates
test,
and
then
you
can
pass
I,
don't
know
which
flag
it
is.
Let
me
see
if
I
can
find
it
there's
a
flag
here
somewhere.
So
basically
put
a
crown
tab.
You
know
that
ECT,
no,
you
found
it.
Okay,
so
yeah
you
just
put
that
and
test.
A
A
A
Yeah,
that's
really
a
great
question
so
from
our
community
and
our
users,
we
have
many
companies
that
do
it
different
way.
The
way
we
recommend
is
just
having
tcrds
as
part
of
your
GitHub
repo,
so
they
are
person,
trucks
there
and
then
you
synchronize,
for
example,
using
Argo,
CD
or
any
type
of
scarcity.
It
can
be
actual
GitHub
actions
as
well.
If
you
want
to,
and
then
you
deploy
that
to
your
cluster.
A
Yeah
so
there's
we
have
some
data
there.
It's
not
fully
customizable.
We
are
looking
into
there's
something
called
CD
events,
so
I'm,
not
sure
which
one
of
you
is
involved
in
that
project.
I
talked
with
some
guys
over
email
and
I'm
really
interested
in
that
see
how
we
would
it
apply
here,
but
right
now,
it's
not
fully
customizable,
there's
some
customizations
here
so
like
can
you
test
how
long
they
serverless
environment?
How
long
like
how
long
it
took
that
action
run.