►
From YouTube: Frontend maintainers weekly 2020-07-02
Description
In this meeting, we talk about Vue components testing best practices.
A
Of
contractors,
a
component
yeah
so
capturing
the
contract
means
understanding
how
component
is
expected
to
function
in
terms
of
house
from
the
outside
perspective,
and
it
is
very
important
when
other
person
is
touching
your
component
to
understand
what
is
safe
and
what
is
not
to
say
for
a
factory.
So
the
classical
B
component
for
component
testing
is
a
black
box.
We
should
not
rely
on
any
of
internal
implementation.
A
We
should
receive
props
as
input
some
other
sources
in
which
we
will
discuss
what
has
a
sources
a
bit
later
generates
as
free
things,
side
effects
like
query
our
API,
for
something
for
our
gradual
and
point
emitting
events
and
template,
which
is
technically
also
a
side
effect,
but
it
is
like
the
main
side
effect
of
any
component.
So
I
highlight
it
is
a
separate
one.
A
Let's
speak
about
each
of
them,
one
by
one.
So
when
you
speak
about
props,
what
I
often
see
it's
not
related
to
test,
but
it's
a
very
first
point:
I'm,
looking
at
always
check
the
balance
of
required
and
optional
props.
Sometimes
we
make
props,
which
I
actually
require
is
optional.
Sometimes
we
are
providing
from
default
values.
It
is
a
very
typical
error,
I
see,
in
our
view,
components.
A
Second,
we
want
to
capture
the
contract.
It
is
always
a
good
idea,
aiding
the
validator
for
crops
where
complex
structure
is
expected
that
sometimes
you
realize
that
this
this
prop
should
receive.
A
very
specific
array
of
data
may
be
just
what,
for
example,
I
thought.
We
expect
an
error
array
of
exactly
three
elements,
each
of
them
representing
each
potential
stage
of
the
component
and
so
on,
and
so
on
and
complex
money
dangers
allow
us
to
make
to
feel
safe,
whether
they
are
consuming
the
component.
A
But
what
we
often
see
just
like
okay,
this
probationary
and
nothing
more
and
I,
feel
like
this
is
not
enough,
because
it
actually
tells
nothing
about
the
structure
expected
data.
It
is
safe
to
write,
complex
money
details,
because,
even
if
it
is
a
hard
to
execute
in
terms
of
computational
power
because
they
run
on
the
inter
element
mode
and
it's
great
to
have
safety
in
development
mode
which
do
not
affect
the
production
you
are.
But
the
problem
is
that
our
validator
checks
the
value
provided
to
the
probe
outside
context
of
the
component.
A
So
it
can't
handle,
for
example,
the
simplest
example:
we've
had
drop-down,
so
we
are
passing
Z
I
turned
to
the
drop-down,
and
obviously
the
value
of
the
drop-down
and
the
value
could
not
be
obviously
should
be
one
of
the
items
provided.
This
thing
could
not
be
expressed
at
least
validator,
because
holiday
doesn't
have
access
to
their
other
probes
to
the
context
and
so
on.
So
it
is
always
great
for
such
component
to
have
and
to
request
from
a
component
occur
the
test
to
verify
that
component
properly
reacts
as
a
bike,
roaming,
error
or
rating.
A
When
we
speak
about
other
sources,
we
means
that
basically,
the
data
could
be
obtained
by
the
component
on
the
via
props,
but
also
we
our
view
axe,
apollo
context
which
provide
inject,
and,
according
to
our
current
testing
guide
and
testing
levels,
it
should
be
mocked
for
component
tests
mocking
it
allows
us
to
understand
which
part
of
this
that
called
remote
state
is
required
for
this
component
to
function,
but
be
Jayne's.
Proper
mops
or
such
stories
is
hard
because
most
could
easily
get
out
of
date
without
breaking
tests.
A
We
updated
our
stone
structure
but
forgot
to
update
it
from
other
component
tests
which
most
resist
or
what
I
usually
see,
and
what
feels
like
a
good
trader
for
me
is
that
when
we
are
mocking
Buicks
door,
we
are
usually
trying
to
reduce
this
source
state,
which
is
usually
separated
in
our
code
base,
but
remote
actions.
Luckily,
we
do
not
have
mutations,
we
do
not
commutation
from
components,
so
this
usually
means
that
as
soon
as
you
mock
actions,
you
do
not
need
to
mock
any
mutations,
because
these
market
actions,
no
mutations,
will
be
ever
called.
A
If
this
is
not
an
option,
you
should
consider
always
using
fixtures
as
much
as
possible,
because
at
least
they
generated
from
back-end-
and
here
we
currently
do
not
have
a
new
way.
At
least
we
do
not
have
at
the
moment
the
thing
to
generate
feature
from
gradual
queries.
This
is
probably
something
we
should
release
back
and
tint
address
and,
like
the
very
very
last
resort,
is
to
use
hard-coded
values
because
it's
like
I,
said
it's
very
easy
to
miss,
because
you'd
rather
you'll
never
know
where
you're
capturing
store,
where
this
store
is
marked.
A
A
That
is
usually
a
fragile
approach
because,
like
you
change
the
component,
which
is
around
the
routine
loading
stage
and
the
still
still
passes,
because
it
is
not
rendering
the
new
component
and
so
on,
and
so
on.
So
when
looking
for
any
kind
of
assertions
for
template,
it
is
always
too
good
to
check
if
we
have
any
kind
of
positive
assertion
for
each
test,
because
test
with
negative
assertions
tries
to
keep
false
positive
and
I
saw
it
multiple
times
when
refactoring
our
view
component.
A
So
when
we
have
events,
we
should
always
for
any
event
in
the
component
have
test
which
allows
us
to
understand
when
this
event
is
emitted-
and
this
is
like
a
great
opportunity
to
utilize
mutation
testing.
So,
basically,
the
idea
is
that
we
should
become
a
blue
component.
You
take
the
name
of
any
image
we
found
like
do
the
JUnit
generate
this
event,
and
the
test
should
turn
red.
In
fact,
any
of
such
a
mutation
survives.
That
means
that
this
event
emitting
in
our
component
is
not
enough
and
the
component
test,
let's
some
import,
important
details.
A
So
obviously,
like
I
said,
it
is
very
important
when
we
are
shallow
multi
component
and
I
want
to
do
a
slight
touch
on
shallow
mount
uses
month.
Topic
that
when
we
use
shallow
mount
of
our
component,
there
is
no
guarantee
that
our
component
could
potentially
emit
the
event
which
we
manually
emit
using
dot,
VM
dot
dollar
and
each
on
the
component.
A
Make
sure
that
our
tests,
like
we
do
not
emit
imposter
even's
future
structures
could
be
easily
updated
to
check
when
we
have
a
midsection
that
we
a
meeting
possible
event.
And
it's
like
a
good
step
for
a
view.
Free
migration,
which
Natale
already
created
epic
and
I,
see
like
a
very
huge
benefit
for
our
testing
code
base
from
doing
this.
A
So
like
red
flags,
when
you
are
looking
for
tests
of
their
first
obvious,
yet
I
still
see
the
test.
No
new
tests
should
use
our
mount
component
helper.
If
you
import
the
view
component,
you
expect
it
to
test
it
with
beautiful
gels
for
new
tests
like
no
new
options.
It
is
bad
idea
to
test
computer
or
data
because
their
component
internals,
we
should
not
in
component
tests,
rely
how
certain
computer
drugs
and
how
internal
state,
which
is
data,
is
represented.
A
For
me,
there
are
no
known
use
cases
when
we
should
do
any
of
this
free,
and
this
should
consider
it
as
a
red
flags
during
flags
which
should
always
raise
a
question
and
have
a
good
explanation
why
we
are
doing
that.
First
of
all,
is
using
the
set
D
to
modify
the
component
data
and
using
the
data
option
to
fast
as
a
date
there's
a
component,
because
there
is
component
internal
state.
Unfortunately,
this
is,
for
example,
the
only
way
we
could
test
right
now.
A
The
component,
which
are
using
view
appala
because
of
your
apologist,
set
the
state
to
the
day
time.
There
is
scenario
C
by
Natalia
how
we
can
do
this
in
integration
tests,
and
this
is
like
what
I
think
this
should
be
definitely
doing
not
only
on
integration
level,
which
is
like
way
too
high
for
this
one,
but
also
on
unit
tests.
So,
like
spoilers
I'm
working
on
approach,
how
we
could
deal
with
this
in
so
I
hope
you
don't
have
an
Arab
scene
coming
from
being
in
the
nearest
week.
A
So
another
one
is
a
great
local
view.
A
beach
was
needed
in
our
karma
tests,
also,
which
was
a
long
long
ago,
available
in
the
future
sutras
documentation,
and
so
now
people
are
copying
and
pay
fees.
So,
basically,
the
rule
is
very
simple.
We
should
use
on
the
lot
of
you
if
we
are
using
cloak
of
Utah
to
use
or
for
introducing
something
like
3
or
X
or
Apollo
to
the
test,
or
sometimes
we
need
to
mock
directives.
A
A
Actually
this
is
it
that
example
is
a
bit
heavy
based.
So
we
are
just
setting
this
loading.
To
is
the
data
we
should
be
passed
to
the
component
and
we
are
testing
the
computed
property.
That
band
approach
here
is
the
set
props
I
was
talking
about.
This
is
a
common
pattern,
seen
in
very
very
in
a
lot
of
old
test
when
we're
creating
component
and
instead
of
creating
it
in
each
test,
we
are
just
doing
the
set
props.
A
You
see
probably
like
this
linkable
pages.
This
is
the
things
which
are
potentially
linked
table
and
we
could
implement
that
so
I
created
epic
in
our
front-end
group
for
github,
yes,
the
into
plug-in,
so
we
could
jump
in
and
create
some
list,
so
we
could
focus
more
on
other
things,
but
right
now,
I
believe
that
all
so
I
will
be
happy
to
hear
your
questions.
A
It
is
just
me
or
just
come:
quality
is
way
better
than
the
normal
that
it
is
like
special
photo
camera
itself,
captured
by
black
magic
at
a
mini
device,
and
it's
like
insane
setup
used
for
streaming
yeah
mutation
testing
by
replacing
at
the,
if
and
view
if
you
true/false,
is
a
good
way
to
just
search
embrace
having
cover
yeah.
Thank
you
Paul.
It's
a
great
note.
It's
just
a
bit
harder
to
implement,
but
it's
like
a
good
way.
I
have
one
day
to
research
where
they
have
time.
It's
really
critical
for
set
methods.
A
A
A
A
It
depends
I
believe
that
if
we
are
just
adding
something
from
directly
from
back
end,
I
feel
they
are
usually
fine,
but
sometimes
we
are
and
crafty
front
end
bases
structure
and
we
have
some
expectation
on
it.
So
if
it
just
goes
straight
from
back
end,
I
think
we
are
fine.
If
we
have
some
fantastic
thing,
it
should
I
believe
it
is
great
to
have
validator
so
I
I
really
love
like
what
component
complains
when
I
try
to
shoot
myself
in
the
leg
is
that
component?
So
let's
do
it?
Slice
yeah.
A
A
Like
yeah
9,
0,
yeah,
yeah
I'm,
not
convinced
that
set
props.
It's
bad
idea
as
long
as
a
component
to
creating
for
each
test,
they're
not
going
to
be
any
leakage
between
test.
Plus
is
just
one
of
the
inputs
as
a
component.
Changing
C's
is
not
is
valid,
like
you're,
creating
additional
complexity
to
the
test,
and
it's
additional
mental
complexity.
When
I
see
set
props
I
think
it
like.
You
have
a
component
and
now
you're
changing
it.
Do
we
a
drive,
you're
testing,
something
which
is
changed
related
like?
A
Please,
don't
make
me
think
I
really
love
like
we
are
directly
setting
the
props
creating
when
we
create
a
component,
because
it's
like
a
no-brainer
I
like
here
is
a
staged
component.
He's
there
checks.
We
are
running
yeah
like
if
there
is
in
discussion.
Testing
Watchers
is
like
the
only
for
me
use
case
when
using
set
props.
So
a
few
things
when
we
need
I
believe
when
we
need,
for
example,
to
call
methods.
A
A
B
So
I
think
with
sentox
two
and
Andrew
brings
up
a
good
point
about
some
organization
of
tests
and
the
fact
that
we've
had
to
migrate.
So
many
tests
from
karma,
like
sometimes
I,
think
to
me
if
you're
using
set
props,
is
not
necessarily
a
blocker
unless
it's
there's
a
huge
readability
hit.
But
the
fact
that
we've
had
to
migrate
some
tests
from
karma
I
can
see
how,
based
on
past
organization
of
the
specs
like
this
just
made
some
things
easier.
B
A
For
our
tests,
which
were
written
in
karma,
like
I,
said
a
lot
of
potential
issues
with
our
old
tests,
but
I
think
for
you
tests,
sometimes
that
ability
will
be
the
same
and
I
believe
it's
my
personal
preference,
not
a
strong
opinion.
That's
a
mental
Lord
of
using
props
data
set
instead
of
probes,
is
lower.
A
A
And
they
start
to
fail
because,
like
I
said,
setting
props
is
modified
internal
state
of
the
component
and
sometimes
is
an
obvious.
Like
my
internal,
like
Beauty
test.
Very
fire
is
also
heat
by
this
one
and
I
really
like,
for
example,
how
how
we
could
read
find
that
blocks
in
the
ruby
specs
with
lat.
We
could
redefining
the
things
inside
the
describe
blocks
and,
but
unfortunately,
I
believe
just
wouldn't
propose
something
similar
for
us.
But
now
so
yes,
we
should
suffer
a
bit.
B
D
D
D
B
D
A
B
B
B
But
if
someone
has
at
the
top
of
this
agenda
document,
there's
an
issue
for
training
topics,
if
someone
has
something
hey,
here's
something
I'd
like
to
talk
about
that'd
be
cool.
Last
handful
of
training
topics
have
been
really
interesting
and
helpful
and
very
organized,
but
don't
let
that
don't
let
that
shy
away
from
sharing
your
unorganized
thoughts.
B
B
Basically,
we
were
in
lining
inside
the
store
state
reading
from
local
storage,
and
this
kind
of
side
effect
these
stuff
would
be
really
nice
kept
outside
of
making
our
stores
very
complex,
so
I'm
a
huge
fan
of
reactive
programming
and
that
making
very
simple
modules
that
react
based
on
each
other
and
so
part
of
that
we
have
a
very
cool
component,
called
local
storage,
sync.
So
anytime,
there's
someone
creating
an
MRI
like
hey.
We
want
to
sync
this
part
of
the
state
to
local
storage
rather
than
reimplemented
the
wheel.