►
Description
In this session we work on making some apollo specs pass and talk about feature specs for the login page.
MR: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/92111
B
B
B
Need
to
yeah
yeah
anyway,
so
edit
and
create
show
the
same
form
it's
just
they
handle,
so
they
need
to
know
like
what
is
the
data?
That's
sent
back
to
the
wrapper
and
do
the
right
apollo
query.
I
just
found
out
that
so
I
was
asking
for
help
with
natalya,
and
so
I'm
passing
this
function
to
handle
the
submit,
and
I
just
found
out
that
that's
incorrect.
It
should
be
emitting
a
event
with
the
details,
so
we
can
also
rewrite
that
yeah
yeah.
B
B
B
A
B
A
D
C
A
A
I
know
that
there's
because
we've
recently
updated
apollo,
and
I
know
that
there
is
a
way
for
apollo
to
completely
forget
about
an
object.
So,
like
imagine,
if
an
object
showed
up
in
multiple
queries
and
I
removed
the
objects,
I
potentially
would
have
to
remove
it
from
multiple
queries.
Like
that's
a
scary
place
to
be
since
apollo.
Actually
like
keeps
track
of
global
ids,
you
can
get
a
have
apollo
forget
about
like
a
global
id,
so
I
I
think
I
was
confused
because
I
was
thinking
oh
instead
of
doing
this
right
great
thing.
A
We
use
this
like
remove
from
cache
this
global
id
thing,
but
that
was
only
under
remove
operation
here,
where
you're
adding
something
or
updating
something.
I
think
I
think
this
is
still
needed,
so
I
and
it's
still
totally
validated,
so
please
just
call
what
I'm
saying.
I'm
sorry,
I'm
sorry
so
yeah.
So
this
makes
sense
so
you're
getting
some
test
failures.
Are
there
other
besides
getting
a
test
to
pass?
Are
there
other
objectives
with
what
you're
wanting
to
do
here.
B
A
B
The
form
will
be
hidden,
that's
what
I'm
actually
trying
to
test
cool
yeah.
So
it
was
passing
before
because
this
just
errored
out
and
then
we
weren't
so
there's
a
test
that
says
like
don't
close
it
if
we're
adding
another
event
or
don't
close
it.
If
there's
errors
which
passed
because
it
errored
here
and
then
it
never
got
here
and
then
it
just
checked
to
see
if
this
was
emitted
or
not,
and
it
wasn't
so,
it
all
grew.
A
B
A
D
And
that's
what
graphql
tends
to
do
most
of
the
time
it
very
rarely
would
return
like
an
error
500.
It
tends
to
return
a
success,
http
response,
but
with
errors
inside
of
the
response
yeah.
So
that's
why
we
tend
to
check
that.
I
think,
but
I
guess
the
other
one
would
be
more
catastrophic
failure,
the
networks
down
or
yeah
an
error,
500
or
whatever
yeah.
D
D
B
B
D
C
B
D
B
B
A
D
B
D
D
D
D
A
D
B
A
D
A
D
D
B
B
B
D
D
B
A
B
A
D
I
found
out
the
other
week
and
I
haven't
really
played
with
it
as
much
as
I'd
like
to
in
vs
code.
If
you,
you
know
how
to
open
a
new
terminal
with
that,
little
plus
in
the
bottom
right
hand
corner
if
you
click
the
arrow
on
it
rather
than
clicking
on
the
plus
and
you
select
javascript,
debug
terminal,
okay,
and
then
you
put
a
break
point
where
you
were
going
to
add
your
console
log
on
line
83
on
the
right
hand,
side
stick
a
little
break
point.
B
A
D
B
D
B
A
D
C
D
C
D
B
D
Know
why
it's
got
it
listed
here
yeah.
I
don't
know
what
it
is
about
that
that
it's
not
liking.
To
be
honest,
so
we
might
have
to
try,
try
your
old
school
console
log
and
see
if
it
logs
to
the
console.
If
it
doesn't,
then
it
might
be
that
it's
not
getting
that
far
or
there
might
be
some
crazy
reason
that
I
don't
understand
why.
You
can't
why
you
can't
do
that.
A
A
A
B
C
B
A
A
A
A
D
B
A
So,
let's
create
a
let's:
after
let
rapper
I'm
used,
I
usually
right
out
right
below
line
63..
I
usually
hate
let's,
but
they
find
themselves.
I
find
them
to
be
highly
useful
in
organizing
determinism
and
tests.
Let's
create
response
spy
here,
spy,
yes
swan
that
actually
may
be
a
cool
movie,
just
declare
it.
Let's
declare
response
by
and
I'm
thinking
way
ahead,
but
let's
also
put
the
apollo
provider
here.
A
A
B
A
And
we
don't
need
to
do
cons,
we're
not
redeclaring
it
we're
gonna,
set
it
up
yeah,
and
so
then
we
don't
need
to
do
the
mock
reset
on
line
84,
because
every
before
each
we're
guaranteed
to
have
a
fresh
thing.
So
we
don't
need
and
then
let's
go
back
up
to
our
function
where
we
create
apollo
provider.
A
B
A
Yep
and
if
you
scroll
down
then
do
we
return
something
from
here?
Yes,
great,
okay!
So
then
that's
if
you
scroll
down
that's
what
we'll
initialize,
if
you
go
down
to
the
before
each
after,
we
create
a
response
by
we'll,
create
mock
apollo
provider
and
assign
that
to
our
shared
variable,
but
it's
going
to
have
to
be
after
we
do
the
response
by.
D
B
A
A
D
B
D
D
B
A
A
A
B
A
A
A
C
D
A
A
B
B
A
B
B
D
B
A
So
emmer,
which
says
these
produce
things,
is
really
really
good
at
having
us
immutably
update
some
level
of
state
and
so
yeah,
so
that
we
don't
have
to
refetch
the
whole
query-
and
I
know
I
just
did
this
thing,
so
I
could
shimmy
this
object
into
here.
We
can
use
emmer
really
nicely
to
just
like
hey.
We
just
inserted
a
value,
don't
feel
like
you
have
to
refetch
everything.
D
D
B
B
B
D
A
B
A
B
D
A
D
D
A
A
A
Is
right?
That's
it
that's
yeah,
we'll
step
over
yeah,
yeah,
okay
and
then
let's
do
source
data
come
on
source
data.
It's
null
all
right.
Okay,
so
record
is
not
working.
We
are
doing
this
cache
write.
Query
thing
all
of
that's
great,
but
what
might
be
happening
is
that
the
variables
aren't
matching.
D
A
B
D
B
B
B
A
C
B
A
D
B
A
On
I
do
want
to
just
clarify,
like
this
setup
of
when
we
create
the
apollo
provider
and
manage
using
just
spies
to
just
mutate
the
return
value
whenever
we
need
to
before
we
create
the
component.
This
is
the
most
deterministic
and
simplest
setup
that
I
have
discovered
for
myself.
When
I
use
this
stuff,
you
don't
have
to
do
it
this
way,
but
this
this
has
been
helpful
for
me.
D
Am
I
right,
I'm
thinking
it's
maybe
slightly
contentious
as
well.
Some
people
are
quiet
that
they're
quite
keen
on
passing
the
the
apollo
provider,
a
mock-up
or
whatever
is
a
variable
to
the
create
rapper
or
create.
What's
it
called
create.
You
know
what
I'm
saying
some
people
don't
like
these
global
this
mechanism
for
doing
it,
but
some.
A
A
Multiple
of
them
they
can
bump
into
each
other,
and
that
was
my
thought
of
what
was
happening
of.
Why
we're
getting
an
error
response
when
that
wasn't
happening
in
the
blog
who
knows
and
so
yeah
I
I
I
don't
like
the
let
keyword
and
I've
created
some
really
really
wild
ideas
for
how
we
can
ensure
that
only
one
collaborator
is
created,
protests
without
needing
this
kind
of
let
and
before
each,
but
this
is
just
the
nature
of
javascript
testing,
so
anyways
yeah
we're
we're
kind
of
that
time,
but
yeah.
A
A
A
Tests
also
aren't
deterministic
we're
even
in
the
same
order.
You
run
them
multiple
times,
because
they're
dependent
on
some
sort
of
date
to
random
stuff,
so
we've
tried
to
make
them
deterministic,
but
I
actually
I
use
that
word
incorrectly,
I
actually
mean
fragile
and
where
tests
are
bumping
into
each
other.
So
the
order
of
this
can
all
of
a
sudden.
A
That's
a
good
word
too,
and
making
the
tests
independent
from
each
other
yeah.
So
we
have
oh
man,
all
the
can
of
worms
that
went
from
ten
percent
is
like
ninety
percent
about
the
first
opener,
but
I'm
going
to
close
it
to
see
if
we
have
ten
more
minutes
for
maybe
yannick
to
share
what
you're
working
on.
C
C
I
am
currently
working
on
a
scam
ui,
that's
what
I
am
no
so
currently
working
on
a
redesign
for
our
login
page,
and
that
is
the
current
state
of
it
and
the
redesign
and
all
of
those
things
these
are
kind
of
going
good.
But
what
is
very
interesting
is
regarding
the
way
we
handle
integration
tests,
because
disimr,
which
includes
this
ui,
is
about
600
lines
of
diff.
Well,
like
it's
huge
our
current,
our
current
login
page
is
perfect.
It
has
a
perfect
test
coverage.
C
That's
absolutely
fine,
and
I
was
asking
myself
like
okay
cool.
I
have
redesigned
this
thing
and
that
is
the
important
part.
Functionality
stays
100.
All
of
these
changes
are
purely
ui
changes.
There
might
be
like
a
heading
missing
or
something,
but
that
is
about
it.
Everything
under
the
hood
hasn't
been
touched,
stays
the
same,
so
I
kind
of
committed
this
and
the
pipeline
immediately
went
green
because
all
of
the
tests
were
still
running
just
as
fine
perfect.
The
thing
with
that
is
our
r
specs.
C
C
If
somebody
decides
to
change
the
old
version
of
it
tomorrow,
he
or
she
would
actually
be
able
to
break
this.
So
therefore,
that's
something
we
might
wanna,
we
we
definitely
wanna
cover.
So
here
is
how
I
am
currently
trying
to
fix
this.
I
have
just
taken
all
the
tests
that
are
kind
of
related
like
this
is.
C
This
is
where
the
600
like
this
comes
from
and
I'm
doing
a
loop
against
my
feature,
flag
and
I'll,
be
turning
it
on
once
and
I'll
be
turning
it
off
the
second
time
and
I'll
just
run
out
of
this
and
that's
the
best
solution.
I
could
think
of.
I
still
it's
it's
kind
of
ugly
since
we're
running
a
lot
of
tests
and
the
loop
is
probably.
D
D
D
A
B
D
A
D
D
A
A
A
You
can
set
the
feature
flag
on
for
the
qa
specs,
but
like
ones
that
run
for
a
pipeline,
they're,
just
gonna
run
and
they're
gonna
run
without
they're
gonna
run
without
the
flag
on
you
turn
this
on
staging
then
what's
gonna
happen.
Is
the
pipeline's
gonna
run
on
staging
to
verify
everything's
good
before
we
actually
make
a
deployment,
and
it
has
to
pass
before
we
can
deploy
so
like
deployments,
get
blocked
the
end-to-end
tests
fail.
C
C
That's
that's
right,
I'm
what
I'm
on
the
fence
about
is.
I
do
like
this.
This
flag
will
probably
not
be
merged
and
then
turned
on
a
day
later,
so
there
will
be
plenty
of
time
frame
to
actually
introduce
an
issue
into
the
into
the
old
version
of
the
login
page.
Therefore,
I
feel
like
we
really
should
have
discovered.
On
the
other
hand,
all
those.
C
Tests
that
we
are
running
on
staging
and
the
different
environments
doesn't
really
matter
which
feature
they're
testing
they
will
have
to
log
in
before
that.
So
if
we
actually
manage
to
break
the
login
page,
I
expect
to
see
a
lot
of
red
a
lot
of
work
on
our
tests.
So
therefore,
that's,
probably
the
most
best
covered
feature
we're
having.
A
A
A
A
C
C
C
A
A
Definitely
I
I
would
think
of
just
what
are
those?
What
are
those
worst
case
scenarios
that
could
go
wrong
and
how
can
we
protect
them?
The
worst
case
scenario
users
can't
sign
up
so
definitely
want
to
verify
that
with
flag
on
and
off
that,
I
can
go
for
the
happy
sign-in
path.
Clicking
one
of
the
providers
is
probably
a
good
idea
doing
the
two-factor
authentication
going
through
that
process
is
a
really
good
idea.
A
C
A
Could
prevent
if
that
stuff,
isn't
loading
or
talking
correctly,
that
stuff
could
prevent
people
from
signing
in
too
it
was
important
that
come
to
my
mind,
just
the
normal
sign
in
clicking
on
one
of
the
providers.
Two-Factor
authentication
capture,
stuff,
slash
talking
to
paul
gv
about
the
caption
stuff.
He
was
working
on.
C
C
A
C
A
D
A
D
Again,
that's
you
know.
We
work
together
on
the
making
a
generic
crud
form.
It's
awesome
to
see
that
we've
got
this.
Generic
list
form
that
handles
like
searching
sorting
with
a
gl
table
embedded
with
tabs
for,
like
inactive,
active
or
open
closed.
It's
really
interesting.
I
haven't
seen
it.
Have
you
not
seen
it
before
paul
am
I
wow,
but
this
is.
D
Should
I
just
let
me
see
if
I
can
just
share
my
screen
for
like
five
definitely
broken
it.
I'm
gonna
share
my
screen
anyway,
just
for
like
five
seconds
before
we
ditch
so
this
is
it
and
it's
broken
today.
I'm
gonna
hit
f5
just
in
case.
What's
it
moaning
about
five,
I've
broken
the
back
end
for
sure.
D
It
with
sort
of
all
columns-
and
even
this
is
part
of
the
component-
to
be
honest,
so
needs
a
bit
of
tweaking.
I
I'm
I'm
a
little
bit.
What's
the
word
disappointed
how
much
we
have
to
build
in
the
back
end,
so
I've
had
to
build
like
more
graphql
resolvers
to
return
the
the
counts.
I
was
kind
of
hoping
there
might
be
something
clever
that
could
reutilize
the
existing
stuff.
But
it's
it's.
It's
awesome.
A
C
D
Back
end
graphql,
endpoints
and
now
I'm
having
to
because
before
it
was
all
front
end,
it
used
to
grab
all
of
them
and
it
did
the
sorting
on
the
front
end.
So
gl
table
did
all
the
hard
work
now
that
it's
paginated,
the
sorting
has
to
happen
on
the
server
side.
So
I've
got
to
basically
write
all
of
the
code
to
handle
all
the
sorting
sites
will.