►
Description
**Result:**
Here's the resulting MR from the first part of the session https://gitlab.com/gitlab-org/gitlab/-/merge_requests/30859
**Highlights:**
00:20 - We start on a spec which is in the middle of being migrated to Jest
17:30 - We talk about the challenges of the codemod to replace setImmediate with setTimeout.
27:00 - We start on migrating `ide/actions_spec`
27:45 - Migrating `spyOnDependency` calls from Karma to Jest
33:30 - We run into a really wild issue where actions passed to the Vuex store are null
47:50 - We are still trying to debug this issue...
52:45 - We are getting pretty close and realize there is a circular dependency between the Vuex store modules and the router
53:50 - We find another piece of the puzzle that the router won't work because we mocked the entire utility module in the spec
59:10 - We retro the problem and discuss the better pattern of exporting store options vs. an actually built store
A
B
I'll,
just
tab
back
and
forth
through
this
I,
don't
use
the
integrated
terminal.
Okay,
so
I've
got
the
first
two
tests
done
so
now.
I'm
on
should
close
the
drop
down.
This
is
part
of
the
pipelines.
It's
the
stage
pinpoint
so
so
far.
I
have
moved,
I've
broadened
view
test,
utils
and
rename
the
component
and
I've
brought
in
wait
for
promises.
I'm,
not
one
percent
sure
if
we
need
it
but
kind
of
what
I've
been
looking
at
with
the
component.
As
of
right
now
is
there's
an
onclick
stage.
B
It
seems
that
the
main
component
is
just
the
actual
component
that
we're
triggering
to
click
on
and
then
I.
There's
this
set
timeout
I
haven't
done
the
code
MA
to
do
all
the
sudden
mediate,
but
I'm
not
sure
we
actually
need
this.
This
needs
to
be
refactored
for
sure.
So
it
looks
like
it's
contained.
It's
looking
for
an
open
class
or
class
to
equal
open.
So
maybe
we
could
do
something
like.
A
A
A
No
get
to
check
this
out
yeah,
so
this
is
this
test
was
returning
before
and
we
were
nullifying
the
rapper
we
were
doing
her
after
each.
We
don't
have
any
done
callback
here,
anything
like
that
happening,
so
we
were
nullifying
it
after
we
tried
to
do
the
expectation
because
we're
creating
this
race
condition.
We
need
to
make
sure
we
have
a
done
callback
or
ideally,
we
return
a
promise.
Okay,
oh
maybe
we
wanna
sound
like
a
good
idea.
Yeah!
That's.
A
B
B
A
Like
when
do
we
actually
create
the
component
and
the
before
yeah
yeah
yeah,
so
I
would
almost
95%
at
a
time
suggest
not
doing
at
the
top
level
before
each
because
you're
always
reading
past
different
props
to
it
you're
doing
a
test.
So
it's
really
helpful.
It
I
would
suggest
not
doing
set
props
at
all
if
you
do
and
that
something
needs
to
probably
be
reorganizing
on
spec.
A
So
what
I
like
to
do
is
create
another
eye
if
I
can't
think
of
a
good
name
for
it.
I'll
just
create
a
top.
A
second
level
describe
called
default
and
then
render
before
I
do
my
gray
component.
But
then,
if
I
have
another
States
I
expect
my
component
to
be
in
I'll
create
another
describe
of
being
like.
Oh
with
this
prop
or
whatever,
and
then
I'll,
then
that's
my
create
component.
A
B
Do
you
think
about
so
what,
if,
what,
if
you
have
a
top
level
before
each
that
creates
the
component,
but
then
you
like
write
it
over
like
so
you
don't
have
to
have
too
many
create
component
calls
what,
if
you
have
a
top
level
before
each
create
component
and
then
like
you,
override
it
like
and
for
a
second.
This
is
a
really
really
good
question.
A
It
may
have
been
called
because
and
like
that
dispatch
water
may
have
been
called
by
an
earlier
create
component,
but
then,
when
I,
you
know
destroyed
it
and
created
it,
some
more.
Whatever
I
now
real
I
have
there's
some
non-determinism
to
what's
happening
here
when
you
call
Cray
component
more
than
once
per
spec,
but
I
think
I
actually
find
that
you
end
up
with
not
too
deeply
nested
specs
and
it's
a
little
bit
stance.
B
C
A
A
A
B
A
B
B
B
B
So
I
might
just
what
do
you
think
about
just
over
writing
the
entire
props
so
right
now,
I
have
it
set
up
with
default?
Props,
maybe
pass
in,
like
all
the
data
for
props
data
or
I
mean
that
way.
I
mean
cuz
up
down,
drop,
update,
drop
down
still
gonna,
say
false,
though
see
I,
see,
I,
see
it
you're
saying.
B
A
A
A
And
you
could
get
really
fancy
with
it.
I
think.
Just
whatever
makes
the
test
more
readable,
you
could
do
like
a
low
merge
if
you
feel
like
that
is
helpful,
but
that
may
add
a
little
bit
more
magic
to
what's
happening
as
well.
So
I've
seen
it
I've
seen
it
both
ways.
Okay,
that's
something
good
to
keep
in
mind
and
I'm.
Guessing
that
merges
objects
together,
merge
yeah
yeah!
A
So
if
I
wanted
to
just
test
like
I,
didn't
care
about
updating
the
whole
stage,
I
just
want
to
test
when
this
one
part
of
the
stage
changes
or
whatever
like
doing
a
merge
could
be
helped
a
little
bit
more
helpful
to
read,
but
it
does
add
more
magic
to
what's
happening
because
if
I'm
looking
at
the
test,
I'll
be
like
oh
well,
this
isn't
a
full
stage.
Prop
house
is
working
and
then
I
have
to
realize.
Oh
we're,
merging
gotcha.
B
A
B
B
D
A
B
B
B
A
Yeah
so
to
abstract
it
a
little
bit
and
that
top
level
before
each
I
love
creating
my
quote-unquote
collaborators
I'll
create
my
store.
I'll
set
up
my
mocks
in
that
top
level
before
each
whatever
I
need
to
do
there,
but
the
subject
under
test:
that's
gonna
be
different
on
each
spec,
and
so
it's
good
to
not
do
that
at
the
top
level
before
you
I
think
you'll
find
that
your
tests
are
become
a
lot
cleaner,
but
these
are
just
ideas,
I
think
I,
think
there's
so
much
that
can
go
on
that
can
really
sway
for.
C
B
A
E
B
A
Okay,
this
is
probably
you
know,
highlighting
something
we
could
add
to
our
code.
Mod
instead
of
replacing
all
set,
timeouts
was
set
immediate,
which
I
think
kind
of
would
work,
but
maybe,
instead
of
replacing
it
with
that,
we
could
in
a
more
fancy
way,
make
sure
wait
for
promises
imported
and
replace,
set
timeouts
away
for
promises.
Yeah.
C
A
B
A
A
I
would
return
the
wait
for
promises
inside
of
here
and
that's
something.
This
is
something
you'll
see
in
tests
or
like
triggering
something
asynchronous
I'm
gonna
return,
my
my
ticker
thing
then
I'm
doing
another
asynchronous
thing:
I
returned
my
ticker
thing
and
then
my
next
expectation
doesn't
have
to
worry,
or
my
next
chain
doesn't
have
to
worry
about
waiting
for
anything
and
then
I
think
I
think
you
did
away
with
just
the
xpect
I.
Don't
think
the
next
take
yeah.
A
B
A
B
A
C
C
F
A
A
A
A
A
A
F
A
Do
you
have
you
all
done
a
migration
for
spy
on
dependency,
I
have
no
it's
the
way.
This
module
works
and
karma
is
a
little
interesting.
You
pass
it
the
default
export
of
the
module.
You
want
to
Spy
something
about
so
here
we'll
testing
our
actions.
We
want
to
Spy
something
about
the
actions,
but
then
the
second
parameter
is
the
name
of
the
module
that
we're
importing
that
we
want
to
spy
on
to
translate.
A
A
C
E
C
A
A
Okay,
it
could
get,
it
could
get
a
little
hairy.
If
there's
we,
we
only
wanted
to
mock
visit
URL,
but
there's
some
sort
of
utility
other
function,
we're
importing
that
we
don't
want
to
mock
like
that,
could
make
our
mock
a
little
more
interesting,
but
it
looks
like
in
this
case
we're
fine,
so
whatever
simplest,
I.
C
E
C
F
A
C
E
A
C
A
Url
my
is
even
if
visit
URL,
you
is
undefined,
redirect
to
URL
should
to
still
be
a
function,
and
that's
what's
weird.
If
you
go
to
the
error
and
this
view,
X
error
is
saying:
hey
you're,
trying
to
create
a
store
that
doesn't
actually
have
an
action
for
this
name.
It's
the
handle,
our
redirect.
Your
URL
is
undefined,
but
it's
clearly
a
function
so
and
it's
blowing
up
not
when
we
try
to
dispatch
that
action
anything
is
blowing
up.
A
E
A
All
right
there's
one
there
and
then
what's
what's
this
one,
it's
the
only
one
gosh,
what's
wrong
with
you
what's
wrong
with
this
store.
What's
that,
what's
that
other
reference,
that's
popping
up,
it
shouldn't
make
a
difference
boom.
Maybe
it's
blowing
up
because
at
this
module
it's
it's
not
a
thing
or
now
I'm.
B
A
A
A
A
A
A
F
A
A
C
A
A
B
A
A
C
B
A
A
A
A
F
C
A
C
E
A
A
C
A
E
A
A
A
C
A
A
A
E
A
A
A
F
A
Because
we
weren't
able
to
import
the
store
all
of
it,
the
same
yeah
if
the
circular
reference
thing
is,
is
not
great
I
think
that
there's
a
Twix,
a
quick
solution
to
it.
If
you
want
to
fix
the
circular
reference
thing
or
if
we
want
to
where
it
at
10
a.m.
or
on
my
time
so
we've
already
been
at
this
for
an
hour
but
I
was
gonna
suggest
was
rather
than
exporting
a
real
router
from
IDE
router.
A
What
if
we
exported
but
I?
Guess
he
can't
do
it,
because
we
reference
router
from
store,
I
was
gonna,
say
what,
if
we
export
a
factory
function
that
takes
in
store
but
store
has
a
reference
to
this.
We
need
to
fix
that
and
that's
something
I'm
gonna
probably
do
soon,
because
that's
problematic
but
I'm
glad
we
were
able
to
debug
it
and
if
she
was
Viking.
C
A
C
A
Am
a
huge
fan
of
that
because
it
also
gets
rid
of
the
whole
singleton
store
thing.
Yeah
I,
think
that
is
a
really
good
idea.
We
we
do.
If
you
look
up,
if
you
do
a
search
for
its
store
options,
you'll
see
that
we
do
some
of
the
like,
create,
store
options
versus
just
create
store,
but
we
haven't
gone.
B
A
Still
keep
a
singleton
reference,
though
of
the
store
thing
which
I'd
love
to
see
us
not
have,
because
that
makes
all
the
tests
wonky,
because
here
in
my
test,
I'm
creating
a
new
store,
but
over
in
my
router
land,
I'm
referencing
the
singleton
store,
like
you
know,
it's
it's
a
mess,
so
this
sounds
like
something:
we
connect
the
dots
as
well
for
a
pattern.
Yeah
I
think
this
is
a
good
I
think
this
is
a
good
idea.
A
F
B
A
Really
cool
with
specs
yeah.
If
someone
wants
to-
and
so
I
asked
this
a
few
like
a
month
ago
to
if
we
see
something
outdated
in
our
Docs,
let's
just
remove
it
and
had
an
issue
saying:
hey
we're
gonna,
we're
gonna
solidify
it
in
this
follow-up
issue,
because
having
I
think
our
dogs
don't
get
updated
enough
because
we're
not
quite
certain
what
the
for
it
is.
But
if
we
know
this
isn't
the
path
forward,
we
should
just
remove
it
because
that
causes
so
much
confusion.
A
A
huge
benefit
to
this
creates
tour
options
versus
creating
the
store
is
in
my
spec.
Rather
than
doing
this,
like
spy
on
dispatch,
I
can
actually
just
overwrite
a
spy
like
I
can
just
replace
this
action
with
a
spy
and
I
love
there,
where
I'm
doing
a
real
store,
but
I
just
have
a
spy
action,
implementation
or
whatever,
and
that's
that's,
that's
pretty
yeah.
This
is
a
good
call.
I
think
this
is.
This
is
a.
This
is
an
offending
pattern.
That's
caused
the
issue.
A
Definitely
the
circular
reference
thing
caused
a
huge
issue,
and
what
was
relate
to
is
that
we
were
mocking
all
of
all
of
URL
utility
versus
just
the
one
function
we
needed
and
that's
another
thing
to
keep
in
mind
when
we
do
this
Jess
mock
is
it's
gonna
mock
it
for
any
file
that
imports
it
and
for
these
utility
folders
yeah,
that's
a
dangerous
thing
to
do
this
is
this
was
informative,
even
though
we
didn't
nicely
have
a
mirja
class
out
of
it.
Yeah.
B
B
A
A
C
A
We've
done
this,
we
have
this
pattern
and
a
few
places
in
our
code
so
doing
a
search
for
create
store
options.
Okay,
this
is
what's
cool
that
as
it
lets
me,
overwrite
these
options
before
I
just
create
this
door,
so
over
here
ooh
we
could
just
create
a
spy
for
the
put
rule
action
as
opposed
to
putting
a
spy
on
all
of
dispatch.
That's
what
I
was
asking:
okay,
yes,
there's
some
patterns
for
this
there's
some
there's
some
trade-offs
to
it.
A
A
Handling
it
this
way
by
creating
some
spy
actions
that
your
components
may
be
looking
for
something
it's
just
a
different
approach.
You
might
find
it
works
better
or
not,
but
if
you
do
a
search
for
create
store
options,
you'll
see
a
few
other
instances
and
tests
how
this
is
helpful,
but
what
I
love
now
is
yeah.
A
Maybe
we
should
just
always
do
this
and
it
breaks
her
singleton
coupling,
which
is
a
really
good
idea,
because
that's
scary
thing
we
do
in
our
tests
is
I,
create
a
new
store
on
our
test,
but
over
in
some
other
land
I
have
a
module.
That's
referencing,
a
singleton
store,
that's
scary!
That's
something.
A
Yeah
yeah,
that's
true!
That's
a
good
point
cool!
This
is
super,
informative
and
helpful
thanks
for
hopping
on
fiddly
and
Paden,
I'm
glad
that
we
also
got
to
have
some
success
with
your
with
your
test.
It
is,
is
she
at
the
beginning,
yeah
yeah
I'll,
paying
both
of
you
and
that
amour
I've
already
got
it
open,
sweet,
Thanks
yeah?
If
you
could
send
it
to
me
too
and
I'll
put
it
on
our
YouTube
description,
all
right!
Okay!
Well,
you
all
have
a
great
rest
of
the
day.
Have
a
good
one
see.