►
Description
In this session we pick up on an old effort and flesh out a helper that adapts graphql-mock-factory. This helper will enable us to remove a lot of duplication caused by creating mock data **and** improve the strength of our tests since it's all based on the schema.
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/57629/
graphql-mock-factory: https://www.npmjs.com/package/graphql-mock-factory
A
B
A
B
Yeah,
so
what
we
yeah,
so
this
was
used.
This
used
to
be
a
mock
day.
That's
just
like
a
a
hard-coded
json
object
that
we
used
in
the
test
so
now
we're
moving
to
generating
it
dynamically
using
our
schema.
So
this
is
one
thing
that's
I
know
has
changed
since
we
last
looked
at
this
is
we've
moved
this
file.
We
should
have.
B
B
A
Well,
and
but
that
brings
up
well,
so
what
do
you
think
of
that?
I
guess
it's
kind
of
like
our
fixtures,
because
now
we
we
have
an
auto-generated
thing
that
we're
requiring.
So
I
guess
just
like
we
have
good
json
fixture.
Maybe
we
should
have
a
helper
for
get
get
lab
schema
that
blows
up
at,
but
I
would
say
it
needs
to
blow
up
at
run
time.
That's
the
thing
is
rather
than
blowing
up.
A
B
A
B
B
Oh,
you
know
why,
because
we're
not
using
this
below
to
do
replace,
and
I
think
it's
because
we
needed
yeah
we
needed
a
way
to
this-
just
gives
us
the
query
itself
and
then
we
need
to
like,
like
hydrate
it
with
the
variables
that
we're
using,
and
we
didn't,
we
kind
of
ran
out
of
time.
So
we
skipped
that
step.
B
B
A
B
C
A
A
A
C
A
E
A
D
C
A
B
E
C
A
B
B
A
A
C
A
B
A
B
A
D
A
A
A
A
B
A
Let
me
think
yeah,
like
you,
look
at
line
33
on
the
left
window
and
we
have
line
21
on
the
right
window.
Like
that's
duplicating
itself.
We
are
also
not
using
the
right
the
real
variables
that
we're
using
in
our
tests,
we've
just
hard
coded
some
variables
to
generate
all
this.
I
kind
of
wonder
if,
for
these
apollo
request
handlers,
we
just
need
to
pipe
them
now
to
this
mock
server
and-
and
so
maybe
we
can
just
export
a
helper
and
just
have
one
helper,
that's
shared
by
all
the
tests.
A
Where
you
just
say
hey
give
me
your
give
me
your
query
and
variables
and
we
can
whatever
rest
args
and
we
can
return
it.
And
now
this
module
on
the
right
side
is
very
domain
agnostic
because
it's
just
other
than
I
don't
know
what
to
do
with
the
mocks,
but
that's
that's
its
own.
That
was
wondering
too,
because
this
is
specific
to
this
query.
B
A
Maybe
yeah,
maybe
maybe
we
also
want
to
just
allow
the
left-hand
side,
allow
the
test
to
be
able
to
create
a
moxer,
so
maybe
maybe
just
enable
somehow
on
the
left-hand
side
to
say.
Oh
here's
here
like,
let's,
let's,
rather
than
because
I
think
we
want
to
do
a
little
bit
of
control
here
to
make,
because
we
have
a
lot
of
tests.
I
think
the
more
we
can
make
this
easier
to
adopt
the
better.
So
I
wouldn't
just
want
to
import
graphql
mock
factory
everywhere.
A
B
A
A
I
think
I
think
we
want
to
have
the
individual
tests
specify
a
they're
going
to
create
something
that
they
can
query
off
of
so
rather
than
rather
than
and
we'll
just
create
one
mock
server
for
them.
I
think
we
can
and
that's
also
a
side
effect
in
our
module,
like
let's
just
create
a
factory
function
for
them
to
say
here's
the
mox,
I'm
going
to
use
for
my
test
and
then
now
you
can
start
hitting
it
with
with
queries.
Do
you
want?
Do
you
want
to
try?
B
A
D
A
B
A
A
A
D
A
A
A
A
A
B
B
A
B
A
So
this
creates
the
mock
server
and
we'll
return
our
query
function,
so
cool
yeah
we're
going
to
create
the
server
and
then
we're
gonna
create
our
query
function
and
then
we'll
return.
The
query
function,
that's
kind
of
how
I'm
playing
on
it
planning
on
doing
it
cool.
So,
let's
go
back
to
here.
I'm
probably
gonna,
we'll
rebase
this
at
some
point.
A
A
A
A
A
C
A
A
B
B
A
A
A
B
B
A
A
D
A
D
B
A
D
E
A
A
B
A
A
A
A
B
A
B
A
B
C
A
Yeah,
so
I
don't,
I
don't
know,
no,
let's,
let's
stick
with
mugs.
That's
a
good
idea!
Okay,
if
you,
if
you
feel
strongly
about
changing
it,
I
don't
feel
strongly
either
way.
So,
no
okay!
So
then
our
query
function
is
gonna.
Take
a
a
quarry
and
I'm
gonna,
I'm
gonna
try
to
do
the
nice
thing,
and
this
can
either
be
that
query
object
or
a
string.
So
we'll
we'll
convert
it
variables
and
then.
A
B
B
A
A
B
A
A
B
D
A
A
A
A
D
A
A
B
A
B
A
A
The
the
challenge
with
encapsulating
that
is
this
is
a
you'll
notice,
is
a
node.js
module
because
it's
run
at
the
at
like
just
integrate
like
the
config
startup,
and
so
I
I
think
we
can
import
common
js
stuff
in
es6
modules,
but
we
need
to
figure
out
a
good
place
to
where
this
stuff
is
going
to
live.
That
would
be
definitely
be
a
to
do
here,
but
not
right,
but
not
today.
A
A
A
A
B
A
A
A
B
A
A
B
A
Point
yep
yep.
I
I
hear
you.
I
think
that
there's
something
I
think
there's
something
nice,
though,
if
about
doing
it,
where
we
get
the
actual
variables,
I
don't
know
why.
I
think
that's
nice,
but
I
think
it's
nice
yeah.
This
should
still
pass.
Let's
see
if
that
works,
sweet
cool,
let's
see
if
we
can
do
the
next
one,
and
this
might
be
an
easy
way
to
start
migrating
this.
This
might
be
the
easiest
way
for
us
to
start
migrating
stuff
over
yeah
you
so
mutation
mock
would
be
interesting.
B
A
C
A
B
A
A
A
Let
me
let
me
delete
this.
Let
me
delete
this.
Our
mutation
mock,
I'm
gonna,
try
to
replace
all
of
our
mutation
modes.
I
know
I
know
we're
at
time.
You
get.
You
got
a
little,
you
yeah!
No,
I
have
nothing
after
this.
So,
okay,
all
right.
Here's,
here's
one
where
we
have
we,
so
I
this
way
of
like
passing
spies
into
like
I
feel
like
having
complicated
factory
functions,
always
makes
things
like
this
complicated.
I
like
having
surprise
I
personally
my
personal
preference.
I
like
having
spies
like.
A
I
know,
I'm
always
going
to
need
to
resolve
our
mutation
result
like
my
component
doesn't
work
without
that.
Like
I
like
having
all
that
here
and
then
let
me
just
in
the
before
each
here's
my
default
and
then
I
can
just
override
some
people.
Don't
like
that
and
that's
okay,
it's
okay,
that
we're
all
different.
A
B
A
A
B
So
I'm
trying
to
think
is
it's
really
cool
that
it
does
that,
but
is
that,
is
it
actually
testing
anything
in
our
code
or
is
it
just
testing
that
our
test
is
passing
in
the
the
right
variables
because,
like
a
question,
yeah
is
there
any?
Is
there
any
case
where
we'd
catch
incorrect
variables
being
passed
in
actual
production
code?
Let's.
A
A
Some
reason
something's
not
being
called
here,
though
this
is
that's
interesting.
I
think
I
think
that's
the
kind
of
thing
that
it'd
be
nice
to
test
against
our
actual
schema.
Is
you
know
here,
we've
even
hard-coded
hey.
I
expect
this
input,
but
we
don't
even
know
if
that's
what
the
back
end
is
expecting
really
sweet
with
get
with
graphql
is
back
end
and
front
end
both
have
a
contract.
We
both
need
to
agree
on,
and
so
now
we
can.
Yes,
I
want
to
still
do
these
assertions.
A
That's
really
helpful,
but
now
I
have
another
layer
of
these
are
also
you
know
none
of
this.
Hopefully
none
of
this
would
work.
I
I
would
get
some
errors
when
trying
to
use
my
mock
gql,
because
I'm
passing
bad
types.
That
would
be
really
nice
information
and
I
think
we
would
get
that
information.
I'm
surprised,
it's
not
super
showing
up
right
now,
but
I
think
that
might
have
to
do
with
for
some
reason
this.
Not
these
calls
not
working.
B
So
I'm
kind
of
comparing
I'm
thinking
about
it.
Like
that,
other
library,
we
use
to
mock
out
rest
apis,
where
what's
that
one
called
it's
like,
also
apollo
something,
but
you
you
say
you
know,
here's
the
rest
api.
I
expect
and
here's
the
variables
and
if
I
receive
a
request
to
this
with
these
variables,
then
return
this
response.
You
mean
like
just
kind
of
what
we're
doing
here.
A
The
axios
mock
adapter
yeah,
that's
that's
the
one
yeah
that's
what
these
resolvers
are.
Actually
that's.
What
the
apollo
provider
this
mock,
apollo
provider.
I
have,
I
almost
have
a
pretty
close
one
to
one
mapping
to
this
mac
apollo
adapter,
this
mac
apollo
and
our
previous
axios
mock
adapter.
It's
very
very
similar.
A
This
is
the
query,
and
this
is
my
handling
function
of
that
and
I
have
found
it
to
be
really
helpful
when
I
treat
it
like
that
to
have
like
shared
variables
for
like
here's,
my
collaborating
endpoints,
which
I
can
configure
at
different
levels
like
like
here's,
my
here's.
My
query,
like
I
would
say,
here's
my
query,
resolver
and
then
here's
my
mutation
resolver.
I
like
having
all
those
up
here,
but
this
is
all
fine
too.
B
A
Yeah
and
so
that's
why,
usually
you
know
if,
if
someone
is
writing
a
good
test
using
all
this
they'll
have
their
resolvers
be
spies,
which
they
can
then
say
hey?
Did
I
hit
the
resolver
with
the
right
stuff?
Yeah,
that's
what
that's
doing,
but
it's
still
all
just
front
end
focus
and
isn't
we
still
don't
know?
A
A
A
A
A
B
A
A
B
B
B
C
A
A
B
B
B
A
A
A
B
A
A
B
A
B
A
B
B
A
So
that's
a
root,
that's
a
pretty
sweet
win,
I
think
of,
but
I
also
think
these
variables
something
tells
me
they
may
also
show
up
here
in
these
these
functions
and
they
can
kind
of
do
dynamic
things
based
on.
I
think
so,
and
that's
impossible
too.
So
I
yeah,
but
that's
I'm
just
I'm
assuming
that
that
should
be
possible,
but
I
don't
know,
but
I
do
kind
of
wonder
to
get
this
ace.
D
A
A
A
B
A
A
A
A
A
C
A
A
A
I
think
that's
this,
oh
this,
because
we
both
of
these
would
cause
an
error
if
the
promise
was
rejected
or
if
it's
resolved
with
errors.
I
think
here's
pass
a
mock
override
object.
Oh
I
think,
with
mock
overrides
you
don't
have
to
do
this
whole
base
thing.
I
think
I
can
just
do
something
like
errors.
A
A
A
I'll
create
a
new
merch
request
too
off
of
this
and
yeah.
I'm
feeling
this
there's
something
here,
I
think
there's
some
quirkiness
we've
obviously
ran
into,
but
I
think
this
is
going
to
allow
us
to
remove
a
lot
of
a
lot
of
this
stuff
and
give
you
more
a
little
bit
more
test
safety.
So
that's
exciting
yeah.