►
From YouTube: CDF Online Meetup June 2023 TestKube
Description
Abdallah Abedraba from Kubeshop explains the need for a shift in testing on Kubernetes. Meet TestKube.io, a new way to manage testing in your cloud-native environment.
A
B
B
So,
even
though
this
feels
like
a
webinar,
if
we
can
act
like
it's,
we're
all
in
the
same
room
and
just
raise
your
hand
or
just
blurt
out
questions
as
you
need
to
I
feel
that
that's
the
easiest
way
to
go
about
this,
it's
makes
it
a
little
more
friendly,
and
that
is
the
point
of
these
calls
is
to
just
have
discussion
today.
Let
me
hang
on
give
you
guys
a
few
minutes
here
got
a
few
more
people.
I
need
to
add
here.
B
B
C
Hey
everyone,
I'm
I'm,
Abdallah
I
work
as
a
product
manager
at
testcube
and
a
little
bit
about
my
background.
I've,
been
doing
developer
relations
and
software
engineer
and
a
product
manager
in
in
the
past,
so
I
kind
of
wanted
to
to
move
quite
a
lot
in
in
the
professional
Spectrum,
but
I
always
stayed
close
to
the
developer.
Tooling
companies
I'm
actually
going
to
share
my
full
screen
here,
because
this
is
where
my
passion
is
is
relying
at
the
moment.
C
You
can
actually
find
me
everywhere
in
in
my
slide
there
in
Twitter
GitHub,
which
I
actually
just
use
as
a
social
media
and
and
yeah.
So
as
as
Tracy
said,
we're
going
to
be
talking
today
about
kubernetes
applications,
I'm
sorry
about
how
to
test
or
kubernetes
applications,
because
I,
it's
really
a
cumbersome
topic
for
which
we
I
in
the
past
have
suffered
part
of
it
because
it's
usually
you
know,
the
components
are
not
easy
to
test,
but
also
testing
hasn't
been
in
mind.
C
You
know
from
the
perspective
of
the
application
developer
in
the
kubernetes
ecosystem,
and
so
usually
everyone
does
it
differently.
The
systems
become
pretty
complex
and
usually
the
result
is
that
people
either
stop
testing
or
don't
test
enough
or
even
worse,
ignoring
the
test
and
fixing
them,
because
it's
just
going
to
require
so
much
time
that
it's
just
you
know
business
is
always
pushing
for
for
for
stuff
to
move
forward
quickly,
and
so
hopefully
what
I
would
excuse
me.
Apologies.
C
What
I
want
to
talk
today
is
is
a
little
bit
about
how
we
can
think
of
this
new
testing
approach
and
even
though
I'm
gonna
be
mentioning
testcube
at
the
end,
I
really
think
that
these
sort
of
thought
processes
can
be
applied
even
without
using
any
sort
of
sort
of
tool,
but
just
keeping
them
in
mind
would
be
would
be
pretty
pretty
important.
So,
in
order
to
to
start
this
discussion,
we
wanted
just
to
mention
how
you
know.
C
Usually
in
the
past,
you
know
before
this
whole
new
git
Ops
sort
of
methodology
of
doing
stuff.
We
were
still
thinking
about
how
can
I
reconciliate
the
state
of
my
cluster,
meaning
what
happens
if
the
application
was
already
deployed
or
what
happens
if
someone
deletes
the
application
after
you
know,
the
pipeline
has
been
run.
C
What
does
what?
Who
does
what
or
actually
what
this?
What?
If
we're
talking
about
tools
and
one
of
the
things
that
we
ended
up,
seeing
this
stuff
as
or
or
like
the
concepts
that
we've
been
thinking
of
them,
is
that
CI
is
actually
in
charge
of
pushing
whatever
changes
somewhere.
It's
usually
a
git
repository
or
a
source
control
in
this
case,
but
CD
would
then
make
the
all
the
work
of
of
pulling
those
sort
of
events
and
then
with
a
little
engine
running
instead
of
your
your
cluster.
C
So
this
is
a
pretty
good
mental
model,
usually
to
think
about
them
where
everything
was
like
a
single
model,
broken
down
and
and
we're
thinking
about
push
and
pull.
But
the
problem
is
or
actually,
let's
shift
gears
a
little
bit
here.
When
do
we
want
when
and
where
do
we
want
to
run
our
tests
whenever
we're
building
applications
in
kubernetes?
And
that's
a
relatively
interesting
question,
usually
the
first
simple
answer
is
you
know
you
want
to
run
the
test
in
on
application,
build
because
that's
what
we
are
accustomed
at?
C
So
you
know
it
doesn't
really
matter
where
you're
running
them,
as
as
as
long
as
they're
they're
happening
in
a
quick
iteration
way.
But
then
the
more
interesting
ones,
I
would
say,
is
the
application
deployment
one
side
to
deploy
the
application?
How
can
I
test
that?
You
know
the
the
whole
components
now
that
we're
working
in
this
distributed
system
is
actually
being
tested
correctly?
C
C
Once
all
those
components
are
actually
ready,
because
you
might
have
deployed
a
single
component
that
was
working
pretty
fine,
but
then
that
single
component
broke
another
part
of
the
cluster
and
until
the
cluster
is
not,
you
know
fully
fully
ready,
it
wouldn't
make
sense
to
run
to
run
those
tests
and
so
because
of
testing
the
CI
has
Still
Still
actually
coupled
to
The
Continuous
delivery
part
just
what
I've
mentioned
at
the
moment
right.
It's
like
I
want
to
run
my
integration
tests
now.
C
I
need
to
expose,
whichever
component,
that
I
deployed
in
my
kubernetes
cluster,
to
be
able
to
be
accessed
from
the
CI
and
then
run
those
tests
against
them,
and
so
one
of
the
things
that
I
think
the
git
Ops
or
flow
has
achieved
is
that
we
have
reduced.
The
number
of
you
know
connectivity
or
network
connectivity
in
this
case
of
different
systems
into
the
cluster.
C
But
if
you
want
to
do
testing,
you
still
need
to
enable
that
connectivity.
You
need
to
expose
that
application
to
be
tested
from
your
from
your
CI
Pipeline
and,
what's
more
is
that
the
CI
still
needs
to
know
the
state
of
the
cluster.
If
you
want
to
run
run
a
test
right,
it's
it's
not
enough
that
you
have
a
continuous
delivery
system
that
is
reconciliating
in
the
cluster
all
the
time.
C
If
you
want
to
run
this
test,
you
want
to
wait
for
that
system
to
to
trigger
an
event
and
then
from
the
CI.
You
know
you're
running
the
test,
and
so
the
whole
point
of
like
push
and
pull
has
been.
You
know
faded
out
a
little
bit
and
usually,
if,
if
you're,
not
very
careful,
you
might
be,
you
know
sometimes
testing
the
old
version
of
the
application
or
or
even
your
testing
before.
Actually
the
cluster
has
been
fully
reconciled
and
to
to
throw
more
fuel
into
the
fire.
C
You
know
there
are
some
some
things
that
a
lot
of
in
a
lot
of
workflow
I've
seen
pretty
common,
is
you
know
the
fact
of
re-running
tests?
Sometimes
the
test
fails
and
I
want
to
rerun
it
and
see
what's
going
on,
but
the
problem
is
that,
if,
if
my
test
is,
is
you
know,
relying
in
this
CI
pipeline
do
I
need
to
retrigue
the
entire
pipeline
to
run
those
tests?
Is
that
a
simple
thing?
C
One
of
the
more
interesting
problems,
I
would
say
is:
is
the
fact
of
being
able
to
save
the
test
artifacts,
the
artifacts
are
just
results
that
your
tests
have
have
generated,
and
so
usually
if
the
test
would
generate
logs,
but
there
are
tools
like
out
there
like
Cypress.
So
Cyprus
is
a
tool
for
front-end
testing.
What
it
does
is
through
JavaScript
code,
you
can
actually
spin
up
a
browser.
C
C
It's
not
really
trivial
and
if
we're
working
in
sort
of
this
agile
or
quick
methodologies,
always
you
wanna,
you
wanna
enable
teams
to
be
able
to
deploy
their
tests,
as
you
know,
as
often
as
they
can
and
whenever
they
want
as
well,
and
so
one
one
of
the
components
that
you
also
want
to
be
thinking
about.
Is
you
want
to
reuse
the
testing
tools
that
are
that
are
out
there?
C
The
cloud
native
testing-
and
that
includes
you,
know,
being
able
to
scale
our
tests
as
much
as
possible.
I.E,
our
applications
are
already
scalable
with
all
with
the
whole
kubernetes
stuff.
Can
we
actually
scale
the
tests
that
we're
running
and
can
they
scale
at
the
at
the
pace
of
our
applications?
You.
A
C
To
make
it
flexible,
you
want
to
make
it
anyone
able
to
to
add
the
test
whenever
they
want.
If
you
want
to
have
a
good
testing
Habit
in
in
your
company
you,
you
really
want
to
make
sure
that
the
flexibility
is
there
to
add
loot,
test
or
even
to
fix
the
existing
ones
and
and
so
on,
and
you
want
to
take
advantages
of
the
whole
kubernetes
automation.
It's
like
we
automated
everything,
but
we
still
haven't
been
able.
C
You
know
to
sort
of
run
tests,
for
example,
when
whenever
my
cluster
is
reconciled,
this
stuff
needs
to
be
taken
advantage
of
in
in
a
in
a
simple
form,
and
so
this
is
actually
what
we
worked
at
a
test.
Cube
you
know
trying
to
build,
and
talking
to
a
lot
of
people
is
the
fact
that
we
wanted
to
do
testing
in
a
kubernetes
native
way,
and
so
Tesco
basically
is
an
open
source
project.
It's
a
cncf
member
and
since
recently,
actually
and
I'm
glad
to
say
this.
It's
also
a
cloud.
C
Sorry,
continuous
delivery,
Foundation
member
as
well,
and
the
whole
goal
of
testcube
is
running
and
orchestrating
tests
inside
your
kubernetes
clusters.
Instead
of
doing
it
from
from
a
different
system-
and
so
you
know,
talk-
is
cheap
I'm
going
to
show
you
a
quick
demo
here
of
what
this
looks
like
so
I'm
just
going
to
go
to
testcube
here.
This
is
the
dashboard
that
you
get
when
you
install
this
cube
in
your
cluster.
C
So
when
you
install
this,
this
community
cluster,
using
Helm
or
whatever,
what
you
get
is
a
dashboard,
an
API
server,
an
operator
and
a
database
where
you
can
see
the
logs.
So
what
you
would
get
is
sort
of
like
this
dashboard
that
you're
seeing
here
where
I
can
see
like
all
of
my
tests
and
then
you
can,
you
know
just
open.
The
test
is
a
specific
test
that
I
have
in
the
cluster
and
and
all
of
the
the
times
that
it's
been
run.
The
interesting
part
of
of
this
test
is
that.
C
C
Be
able
to
see
that
you
know
there
are
some
logs
generated,
and
the
interesting
part
here
is
that
these
logs
are
actually
saved
inside
the
cluster
and
all
these
metrics
that
you're
seeing
is
actually
saved
in
inside
of
the
the
kubernetes
cluster.
So
you
can
always
have
access
to
your
own
data
and
and
see
what's
going
on
with
the
state
of
the
cluster.
Usually,
this
is
also
very
helpful
for
sres
signal.
C
There
are
interesting
things
that
you
can
actually
trigger,
for
example,
those
tests
from
from
a
specific
kubernetes
event.
So,
for
example,
if
a
specific
deployment
with
the
label
you
know
jmeter
was
modified.
For
example,
then
you
can
trigger
an
action
of
test
script
like
hey,
run
this
test
and
so
on.
So
this
is
a
little
demo
of
what
this
Cube
can
can
offer.
C
You
feel
free
to
to
check
it
out
yourself,
but
the
the
idea
is
that
testcube
actually
reuses
every
testing
tool
out
there,
and
it's
not
you
know
creating
or
Reinventing
the
wheel
here.
There
is
a
vast
ecosystem
of
testing
tools
out
there,
and
so
everything
that
we've
done
was
just
basically
package
those
testing
tools
and
enable
anyone
to
be
able
to
add
them
to
your
kubernetes
cluster
pretty
easily
by
you
know,.
C
Them
eventually,
but
you
can
actually
bring
your
own
and
so
Tesco
basically
does
the
they
have
a
lifting
of
of
running
those
tests
in
in
kubernetes,
as
I
said
before,
you
don't
need
to
containerize
these.
These
testing
tools
that
you've
We've
mentioned
we
already
containerized
them
for
you
and
and
actually
maintain
them,
but
you
can
also,
you
know,
bring
your
own
testing
tools.
Eventually,
everything
in
kubernetes
is
a
container
right.
C
The
interesting
part
is
that,
because
the
tests
testcube
runs
the
tests
inside
the
kubernetes
cluster,
you
don't
need
to
expose
your
application
to
the
Iowa
world.
You
know
outside
of
your
company's
VPN,
so
your
CI
CD
system.
Sorry,
sorry,
your
CI
system
I've
made
the
mistake
that
I
actually
started
with
that
I
complained
about
in
the
beginning,
which
is
mentioning
CI
CD
together
yeah,
you
don't
need
to
give
access
to
your
CI
systems
to
test
your
applications.
Everything
happens
in
inside
the
cluster,
and
so
you
can
have
this
totally
air
gapped
environment.
C
C
One
of
the
cool
things
is
that
you've
seen
me
running
that
test
a
couple
of
times,
yeah
test.
You
can
scale
your
your
test
and,
and
you
can
run
them
in
parallel,
which
could
be
a
huge
Time
Saver
for
for
a
lot
of
use
cases
again,
you
don't
need
to
write
like
complex
scripts
in
your
CI
pipeline
to
be
able
to
to
do
all
of
this
sort
of
stuff
and
then,
which
you
know
in
turn,
just
makes
the
entire
CI
CD
pipeline
much
more
much
more
simpler
in
that
case.
C
So
what
what
you
know
folks
do
before
using
testcube
is
actually.
This
is
on
the
left
side.
You
can
see
a
CI
system
where
you're,
building
and
deploying
and
then
running
a
test
and
then
a
second
test
and
a
third
test
now
with
testcube
everything
is
being
run
instead
of
like
the
kubernetes
cluster
and
so
from
your
the
CI
pipeline.
Just
visually
just
looks
smaller,
because
more
components
have
been
offloaded
into
into
a
different
into
test
cube
in
this
case.
C
So
the
cool
thing
with
test
cube
is:
it
offers
the
different
mechanisms
to
run
those
tests.
You
can
run
them
on
schedule,
it's
just
a
chrome
job
in
kubernetes.
You
can
run
them
manually
through
the
CLI
or
the
dashboard
that
I
just
showed
you
so
in
case.
You
want
to
rerun
a
specific
test.
You
can
just
click
it
there
or
you
could
also
run
it
from
from
the
testcube
API.
C
So,
for
example,
if
you
have
systems
that
want
to
interact
programmatically
with
your
cluster
to
test
stuff
and
if
one
of
the
the
things
that
I
like
the
most
is
obviously
being
able
to
run
test
on
annotated
labels,
kubernetes
kubernetes
objects.
So,
for
example,
if
a
pod
has
been
recreated,
then
just
run
the
test.
Let's
make
sure
that
everything
is
is
working
fine
and
then
the
interesting
part
which
I
will
be
talking
more
about.
Is
you
know,
reacting
to
Cluster
events
or.
C
C
Because
again,
this
is
standard,
but
you
know
also
what
to
expect,
and
so
one
of
the
one
of
the
things
that
we've
done
at
testcube.
This
is
the
the
City
events
website.
It's
actually
recently
contributed
to
to
the
events
that
are
standardized
by
the
the
City
events,
so
you
have
here,
for
example,
the
existing
events
that
were
created
a
while
ago,
for
example,
for
source
code
control.
C
So
if
my
git
repository
gets
updated,
then
I
want
an
event
being
triggered
to
react
to
it
in
some
way
and
best
give
just
actually
collaborated
by
adding
the
testing
events
here.
So
the
the
thing
that
we
want
to
do
is
you
know,
sort
of
standardize
the
way
that
we
communicate.
What
sort
of
has
been
run,
and
so,
if
you,
if
you
see
them
this
is
actually
still
in,
maybe
it's
not
published
or
actually
it
is.
C
We
can
see
that
there
are
three
sort
of
events
when
when
a
test
is
run
or
a
test,
Suite
has
been
run,
and
so
there
are
some
some
standard
predicates,
which
is.
This
has
been
queued,
started,
we
even
finished
and
something
has
been
has
been
published
and
then
you
can
actually
go
and
see.
What
is
the
payload
that
you're
expecting
from
from
this
test?
C
And
so,
for
example,
there
is
an
outcome
that
says
that
the
test
has
passed
and
failed
or
canceled,
hopefully
with
the
CD
Foundation
we
can
build.
You
know,
tools
that
are
more
interoperable.
You
know
testcube
and
rcd
and
any
tool
that
that
is
that
is
working
in
the
continuous
delivery
space.
They
can
talk
to
each
other
pretty
easily
without
needing
to
reinvent
the
wheel,
every
time
that
that
we're
trying
to
achieve
this
sort
of
efforts.
C
So
this
is
all
that
I
wanted
to
talk
to
you
about.
Let's
give
again
is
an
open
source
project,
so
you
can
go
ahead
and
check
it
on
in
GitHub
we
have
a
Vibrant
Community
in
Discord,
where
we're
trying
to
talk
as
much
as
possible
with
with
anyone
who
comes
there.
So
please
hop
along
and
and
yeah
follow
us
on
on
Twitter.
This
is
all
I
wanted
to
share.
Thank
you.
So
much
then
I
see
already
Dave,
with
with
your
hand,.
A
A
C
A
C
So
at
the
moment,
as
I
showed,
that's
a
pretty
good
question
by
the
way
I
really
like
it,
as
I,
showed
like
the
sort
of
three
events
that
we're
that
the
CD
events
is
supporting
at
the
moment,
and
these
are
the
ones
that
we
just
thought
of
to
to
contribute.
Initially,
as
as
you
can
see
here,
is
the
test
run
and
test
Suite
run
and
test
output.
But
then
these
you
know,
the
idea
at
the
moment
is
that
more
and
more
sort
of
tools
start
supporting
these.
C
These
sort
of
events,
not
from
the
point
of
emitting
them
like
test
cube,
is
doing
at
the
moment,
but
also
from
the
point
of
like
receiving
them,
and
you
know
interacting
with
them.
So
at
the
moment
I
don't
think,
but
actually
it
might
be
possible
in
in
the
test
output
event,
you
can
actually
see
what
sort
of
event
was
was
published
and
the
content
of
that
event.
C
C
B
I
just
want
to
point
out
the
test
Cube
took
on
the
task
of
starting
the
conversation
and
starting
to
build
out
this
vocabulary
around
CD
events
for
testing,
we're,
hoping
that
we
have
more
testing
solutions
that
can
contribute
to
this.
So
if
you
have
a
particular
vendor,
I
would
say
make
sure
that
they're
aware
of
CD
events
because
they've
exactly
what
you
asked.
The
whole
point
is
to
have
sort
of
a
broker
that
can
broadcast
so
that
everybody
can
pull
the
information
as
needed
and
and
test.
B
Cube
has
started
that
conversation
and
from
the
CD
perspective.
We're
super
appreciative
for
them
to
start
that
conversation,
but
we
need
more
testing
tools
to
have
to
be
part
of
it.
Absolutely
yes,
I
have
a
question
for
you.
You
said
you
have
a
you,
have
a
you:
have
a
database
in
each
cluster.
Is
there
do
you
have
apis
that
can
access
that
data
for
other
tools
without
CD
events
to
access
them,
yeah.
C
That's
actually
one
of
the
ways
that
you
would
Implement
what
Dave
is
actually
asking
is
like
once
you
receive
the
the
event.
One
of
the
the
elements
of
this
event
is
that
there
is
a
Yuri
where
the
the
artifact
actually
of
is
has
been
deployed
at
so
you
can
see
here
it's
actually.
This
is
an
internal
cluster
and
hopefully,
if
you,
if
you
get
to
this
Yuri
or
URI
you'll,
be
able
to
to
access
those
those
artifacts.
A
C
B
And
I
asked
that,
because
of
another
open
source
project,
that's
the
artillius
project.
We
we
gather
data
on
these
objects,
so
we
could
potentially
through
CD
events
or
directly
through
your
API
I'll,
start
reporting
on
this
on
the
data
for
each
of
the
components
in
an
application-
and
that
is
my
other
question.
How
does
testcube
handle
right
now?
Can
you
so
you're
you're?
Are
you
making
the
assumption
that
in
each
cluster
you
have
test
Cube
running,
so
it's
testing
all
of
the
namespaces
within
that
cluster?
B
C
Yeah,
that's
the
the
coolest
part
of
like
not
needing
to
expose
any
of
these
sort
of
applications
in
any
namespace
to
the
outer
world.
Just
for
the
sake
of
being
tested,
you
know
a
dashboard
or
a
front-end.
Application
is
usually
exposed
out
there.
So
you
can,
you
can
run
a
test
from
whatever
you
want,
but
usually
an
API
that
is,
that
is
internal.
B
C
There's
a
lot
of
people
that
are
running
these
after
their
CD
systems,
like
flux
and
argue
City
have
have
have
finished
so
once
the
CD
system
applies
and
we
constantly
it's
cluster,
it
generates
an
event
which
test
group
then
listens
to
and
then
is
able
to
to
run
those
those
tests.
The
idea
is
that
you
want
to
make
running
those
tests
as
flexible
as
possible
and
not
just
from
a
CI
perspective.
C
C
Most
of
these
tests
are
just
like
Chrome
jobs
that
are
being
triggered
every
every
once
in
a
while
to
test
it.
So
you
can
eventually,
under
the
hood,
answering
again
your
question
Tracy.
What
we
are
doing
is
just
creating
a
kubernetes
job
that
then
runs
the
test,
and
then
we
manage
the
the
life
cycle
of
that
job
and
obviously
save
the
output
of
of
that
job.
C
A
A
B
Thank
you
and
let
me
just
point
out
that
if
you
want
to
have
a
deeper
conversation
with
the
test
view,
contributors
Cube
shop
is
the
company
who
has
contributed
a
test.
Cube
and
their
Discord
channel
is
listed
there.
So
cubeshot
it
just
cubeshop
at
Discord
is
a
place
to
find
them
or
go
to
testcube.
You
know
the
the
website.
Is
it
testcube.dev
I.
B
You
should
be
able
to
find
that
and
of
course,
every
open
source
project
is
always
looking
for
contributors.
I
know
that
for
absolute
facts.
So
if
testing
is
your
thing
please
reach
out
and
let
them
know
that
you
would
like
to
become
a
contributor
contributors.
You
know
are
have
many
levels:
it's
not
just
code
contribution,
it's
testing,
it's
documentation.
It's
project
management,
it's
Outreach!
It's
doing
it's
doing
these
kinds
of
webinars
and
CD
and
CDF
meetups.
So
there's
lots
of
ways
to
get
involved.