►
Description
In this pair session we talked about what to do with the remaining karma specs, and also started working on moving a [`tooltip_on_truncate`][1] component to [`gitlab-ui`][2].
0:00:00 - Intro to the problem
0:00:30 - What to do with balsamiq_viewer_browser_spec.js?
0:02:05 - What to do with lib/utils/browser_spec.js?
0:19:10 - What to do with dashboard_resize_browser_spec.js?
0:29:20 - What to do with tooltip_on_truncate_browser_spec.js?
0:31:50 - Let's start moving tooltip_on_truncate component!
[1]: https://gitlab.com/gitlab-org/gitlab/blob/c43156cd927a0010edc1f68e87cf75d73cb8ab89/app/assets/javascripts/vue_shared/components/tooltip_on_truncate.vue#L1
[2]: https://gitlab.com/gitlab-org/gitlab-ui/-/merge_requests/1614/
A
A
But
I
actually
cheated
a
bit
and
had
a
look
into
this.
So
I
had
the
following
idea:
I
was
like
okay,
we
just
have
like
five
spec
files,
so
maybe
let's
have
a
look
at
these
spec
files
on
a
high
level
first
and
decide
whether
we
should
port
them
to
copy
power
or
not,
but
they
are
actually
portable
right.
So
let's
have
a
look
into
this.
Balsamic
viewer
browser
spec
and
I
think
that's
a
great
candidate
for
being
ported,
because
it
essentially
loads
a
balsamic
file
and
then
checks.
A
C
B
A
A
A
Yeah,
it's
used
in
scroll
top
right,
it's
using
scroll
to
element
scroll
to
element,
yeah,
and
I
mean
I
have
a
complete
other
grievance
of
scroll
to
element,
and
I
think
we
even
have
an
issue
of
replacing
it
with
a
native
scroll,
because
right
now
it
uses
jquery.
So
we
could
even
be
like.
We
drop
the
test
and
say
hey.
We
have.
A
C
D
A
C
A
A
A
A
That
being
said,
it's
all
a
bit
ugly
because
we
actually
have
some
mock
data.
We
compare
it
to
and
we
do
it
with
a
pixel
tolerance
comparison.
I
don't
know
to
be
honest.
The
easiest
way
probably
to
deal
with
this
is
by.
Extracting
this
whole,
I
can
shenanigans
into
gitlab
ui,
even
though
it
might
not
belong
there
as
a
helper
function,
because
then
we
could
just
do
the
combination
of
sorts
in
gitlab
ui
and
have
the
screenshot
test
doing
the
whole
comparison
for
us.
C
C
Are
you
meaningful,
screenshots,
yeah?
So
look
this
kind
of
thing.
Where
we're
like
doing
images,
I
feel
like
yeah.
We
can
unit
test
this,
but
we're
gonna
be
mocking
a
lot
of
stuff
around
it
and
it's
like
the
real
question
is:
does
it
look
like?
Does
it
look
right
and
we've
talked
a
lot
about
doing
a
git
lab
project
storybook
for
automated
screenshot
testing.
A
So
I
I
I
think
I
mean
the
thing
you
can
test
is
you
can?
Actually,
you
know,
what's
probably
the
yeah?
So
the
problem
is
why?
Why
do
we
do
this?
Because
we
have
the
different
fluffy
cons
depending
on
the
environment
right
like
the
gitlab
canary
icon
and
the
gitlab
localhost
green
one?
And
we
do
this
in
order
to
combine
it
with
the
current
status
and
have
that
on
the
pipeline's
page.
A
A
C
A
Yeah,
so
by
the
way
we
always
had
problems
in
the
past
as
well,
because
the
browser
sub
subtly
change
with
the
canvas
rendering.
So
what
we're
actually
doing
is
like
we
get
data
urls,
and
then
we
compare
it
with
some
pixel
metro
kind
of
thing.
So
it's
yeah
and
I
don't
know
I
mean
we
also-
could
move
it
to
jest.
A
It
looks
right,
yeah
equaling,
the
image
equally
yeah,
you
know
what
I
mean.
Finally,
though
we
implemented
it,
and
I
know
that
because
I
implemented
it
with
our
own
metro,
so
we
have
there's
like
this
pixel
match
library
and
to
be
honest,
like
as
we
have
this
own
metro,
we
probably
can
port
it.
This
part
that
it
looks
right.
We
probably
can
just
all
right.
C
C
Yeah,
but
it's
also
we're
using
that
we're
using
the
canvas
internals
to
test.
Does
this
visually
look
right
and
yeah
doing
some
sort
of
I
wouldn't
want
to,
and
even
though
this
is
like
a
super
small
function
like
I
still
ideally
we're
not
losing
any
coverage,
it
would
be
nice
to
keep
some
sort
of
the
visual
regression
here.
The
fact
that
we're
doing
this
canvas
contact
stuff-
I
don't
know
what
what
do
you
all
think
nico
jose
of
italy.
F
A
I
mean,
if
we
have,
I
mean
we
often
mock
browser
apis
right
or
there
is
like
implementations
of
browser
apis
like
fetch
or
whatnot
in
so
if
we
trust
those
right,
why
wouldn't
we
trust
like
a
canvas
implementation
that
would
work
ingest
right,
because
right
now
we're
just
checking
that
it
looks
the
same
in
in
in
chrome.
Essentially,
right
doesn't
even
mean
that
it
looks
the
same
in
firefox
or
another
browser
and,
to
be
honest,
like
we
have
the.
A
C
B
D
C
C
A
I
mean
I
mean
so
this
is
why
I
mean
like
hey,
even
even
just
remove
you
know,
we
don't
have
this
just
browser
environment
right
now
as
a
maintainer.
Would
you
generally
be
fine?
If
we
remove,
for
example,
these
overlay
tests
and
say
hey,
we
need
to
follow
up
for
this,
because
the
whole
idea
is
that
in
a
relatively
short
time
frame,
we
remove
this,
because
it's
just
money
that
we
burn
and
energy
that
we
burn
that's
useless
right.
This
is
a
function
that
has
been
tested
now,
for
I
don't
know
right.
C
It
will
change
like
that's.
The
thing
is
this
function
will
end
up
changing
and
some
community
contributor
is
going
to
find
something
of
like
oh,
we
could
do
something
here
and
when
it
happens,
you
could
ask
yourself:
am
I
gonna
end
up
manually
testing
this
anyways
like
so,
if
I'm
manually
testing
things
anyways
like
and
we
don't
have
a
whole
lot
of
automated
tests
for
just
this
thing
like
what
is
the
real
value
of
here?
C
A
I
mean,
if
it's
visual,
I
actually
would
say,
hey,
maybe
maybe
moving
it
to
gitlab
ui-
would
be
a
possibility.
That's
just
like
combining
these
two
icons
and
using
that
in
the
test,
and
I
mean
we
could
write
a
little
test
component
around
it,
because
it's
basically
hey
call
this
function
on
mount
and
put
it
in
an
image
tag.
And
if
it
looks
the
same,
it
looks
the
same
right.
C
C
A
A
Okay,
cool
sounds
good
because
yeah
and
all
these
others
we're
basically
testing
this
function
multiple
times
right
like
yeah.
We
test
that.
It's
that
it's
built
correctly
and
then
we
test
that
we
can
set
it,
but
we
also
test
that
the
set
one
you
know
matches
the
thing
and
then
at
some
point
you
also
has
to
have
to
trust
the
browser
kind
of
like
hey.
If
I
set
a
fluffy
con,
the
favicon
changes
right
like.
A
A
A
C
A
C
I
think
this
one
can
be
moved
to
just
because
the
bit
that
we're
really
interested
in
is
that
get
bounding
client
wrecked.
Given
that
and
the
window
state
like,
are
we
calculating
this
correctly
and
we
could
do
a
lot
more
test
coverage
than
I
see
what
we
have
right
here
and
not
couple
ourselves
to
this
specific
browser
environment
where
yeah?
And
so
I
think
that
this
is
a
good
unit
test.
Opportunity
it'd
be
nice
to
have
some
of
those
just
while
we're
talking
about
everything.
C
It'd
be
nice
to
have
some
of
those
specific
instances.
Those
specific
use
cases
like
in
this
merge
request
widget
when
it's
in
the
viewport.
We
do.
This
thing
like
it'd,
be
nice
to
have
that
covered
in
a
capybara
spec
and
I'm
not
untied
just
to
make
sure
we
have
everything
working
in
integration,
but
that's
not
necessary
here.
So
yeah
cool
move
to
suggest
and
we're
done
with
the
file
cool,
yeah
dashboard.
A
E
Isn't
this
a
good
candidate
good
to
go
straight
to
capybara
yeah
yeah,
the
problem?
The
problem
of
this
is
that
is
testing
stuff
that
are
completely
far
from
what
he's
actually
trying
to
test
right.
If
I
remember
correctly,
I
think
you're
right.
I
think
this
is
a
full
mounted
test,
yeah
testing,
something
some
something
else
behavior
somewhere.
So
if
we
can
understand
the
behavior
and
move
it
to
capybara,
probably
this
is
a
win.
F
There's
only
one
problem
I
can,
I
can
attest
to
this
one,
because
I
will
work
on
this
and
a
while
back
and
the
problem
with
the
metrics
dashboard,
and
this
is
something
that
we're
currently
working
on,
is
that
this
is
coupled
with
a
premium
server
or
a
kubernetes
cluster,
and
the
problem
is
that
we
in
capivara,
we
cannot
mock
those.
So
this
is
something
that
the.
F
C
F
A
couple
of
things
that
that
come
to
mind
are
one:
we
need
a
full
browser
environment
because
this
is
not
dependent
on
us.
I
don't
know
why
we
did
this
in
the
first
place,
but
I
think
it
was
because
some
rather
contin
rather
weird
bug
where
replacing
the
window
didn't
make
e-charts
fire
the
resizing
event
and
he
charged
all
of
a
sudden
just
didn't
resize
the
charts
at
all,
and
the
other
reason
that
this
is
not
possible
for
us
to
move
to
jazz.
Besides
the
browser
environment
is
that.
F
E
A
What
would
we
do
about
this
test,
giving
the
constraints
that
you're
describing
because
to
me
it
sounds
like
I
mean
it's,
a
bad
idea
to
remove
coverage,
because
it
seems
like
a
lot
of
your
stuff.
Is
all
this
monetary
stuff
is
kind
of
not
covered
here
right
and
other
things
that
you
described
sound
like
hey.
Each
house
is
weird
and
hey:
hey
whatever
dependencies
dependencies
dependencies
where
I'm
like.
C
F
I
think
heavy
down
I'll
bring
this
up
to
the
next
monitor
and
call
and
I'll
I'll
try
to
convince,
because
I
think
the
biggest
opponent
to
this
one
I
have
to
persons
in
mind
that
might
not
want
this
to
be
removed
and
I'm
thinking,
perhaps
clement
and
perhaps
miguel,
but
I
think
the
raj
andrei
and
some
of
the
other
team
members
from
the
monitoring
team
will
not
be
opposed
to
this.
Because
I.
C
F
F
C
And
that
might
be
all
we
need,
though,
that
might
be
why
it
wasn't
working.
So
since
then,
we
now
have
like
a
standard
and
and
you're
aware
of
this
ip.
I
think
we
have
a
standard,
resize
observer,
intersex,
intersection
observer
like
mock,
that
we
can
use
to
trigger
events
and
stuff
that
we
need.
I
don't
think
we
were
doing
that
before.
C
E
C
Right,
okay,
I
I
like
I
like
hoes.
I
like
the
idea
of
of
moving
this.
Not
let's
not
just
delete
this
back
because,
even
though
spec
is
is
funky
like
that
kind
of
is
a
sign
that
something
underneath
is
funky
and
that's
something
we
want
covered.
So
I
would
suggest,
let's
not
remove
it,
but
I
would
say:
hey
we're
blocked
at
removing
karma
until
we
find
a
nice
home
for
this
test
coverage,
and
that
might
be
that
might
be
talking
to
our
test
engineers
too.
C
D
A
A
A
D
D
C
A
A
A
A
C
A
A
E
C
There
is
one
instance
where
it's
made
a
difference
when
someone's
needed
to
mock
like
the
a
certain
component
or
whatever.
If
you
we
mock
at
the
index,
it's
different
than
mocking
at
the
path
of
that
component.
That
thing
has
that
thing
has
come
up,
but
I
think
in
our
case
it's
not
a
deep
big
deal.
Okay,
yeah!
That's
it's
good!.
D
A
Unfortunately,
you
can't
drink
anything
because
czech
republic
has
a
zero
alcohol
limit
thing
and
on
every
routine
control.
You
have
to
do
an
echo
test,
so
it's
no
no
drinking
gear
and
driving
in
the
evening
or
something
right,
oh
wow.
So,
but
apart
from
that,
we
had
a
good
time.
Nice
food
saw
all
the
all
the
sites,
and
hopefully
the
next
contribute
will
be
there
so
that
you
all
can
see
the
sites.
That's
awesome.
A
I
don't
know
it's
it's
all
nice,
it's
nice
and
old
buildings,
but,
to
be
honest,
like
I
think
the
problem
is
that
so
in
our
case
we
were
just
there
one
day
and
the
white
driver
has
been
to
product.
So
we
basically
did
the
the
git
lab,
I'm
the
first
time
in
prague,
2
right,
so
I
would
probably
visit
some
museums,
especially
around
some
around
certain
painters.
A
B
E
E
A
C
A
A
D
C
E
F
C
A
D
A
A
A
C
A
A
A
C
A
A
C
Lock,
oh
yeah,
so
we
did
just
we
just
consoled
the
response
of
focus.
So
how
do
you
and
that's
the
next
question?
How
do
you
programmatically
trigger
a
tooltip
and
there's
and
we're
using
bootstrap
tool
tips?
There's
a
way
to
do
this.
I
think
it's
actually
a
lot
easier
than
what
we're
doing
right
now.
C
E
C
C
C
C
Yeah,
if
you
look
at
the
third
example
and
then
the
text
right
below
it
says
to
open
all
simultaneously
emit
the
id
argument.
So,
but
what
we
might
need
to
do
is
a
is
a
next
tick,
because
tooltip
on
truncate
might
be
thinking
about
something
right
now.
So
if
this
doesn't
work,
I'd
like
to
try
a
next
tick,
and
if
that
doesn't
work,
then
I
don't.
C
A
A
C
D
C
A
A
C
C
A
C
A
C
C
E
C
You
think
about,
I
don't
know,
I
don't
know
yeah,
I'm
a
little
frustrated
that
this
isn't
working.
There's
other
events,
there's
other
tooltip
events.
We
can
listen
to
looks
like
bootstrap
emits
a
bv,
tooltip
enabled,
and
so
maybe
we
can
just
listen
to
that
and
then,
when
it's
enabled,
let's
try
to
show
it.
If
you
go
down
to
yeah
those
are
some
global
events
that.
D
C
C
C
A
C
A
C
C
B
C
C
A
C
C
A
C
A
A
But
have
a
look:
they
they
actually
focus
on
the
on
the
thing
you
see
that
you
see
the
focus
outline,
so
they
might
be
so
doing
something
in
there.
That's
a
good
mountains.
This
next
take
element,
query
selector
button
focus,
so
they
actually
do
exactly
the
thing
right.
Let's
maybe
maybe
give
it
a
try
and
in
the
story
shots
back.