►
Description
In this session we pair up on testing an MR that fixes the artifacts dropdown behavior. We also pair up on mocking the locale module to help with unit test determinism across environments.
00:00 - Testing artifacts dropdown contribution
18:30 - Mocking locale modules
- https://gitlab.com/gitlab-org/gitlab/-/merge_requests/128531
A
A
A
A
B
C
B
A
D
B
A
A
A
A
B
A
D
A
I
wonder
if
there's
actually
instructions
for
that
here,
oh
yeah,
great
artifacts,
the
roar
template
project
fits
perfectly.
Oh,
maybe
I
should
just
do
that.
Let's,
let's
leave
this
and
create
the
new
template
project.
The
project
create
from
template,
use
template
another
one
of
those
block
rocking
Warren.
D
A
B
B
B
D
C
A
B
A
B
C
B
A
A
A
A
B
B
A
B
B
B
A
Yeah
yeah
yeah:
oh
look
at
that!
I
click
on
this
one
yeah
and
the
file.
Okay,
this
isn't
anything
related
to
this
Mr,
but
I
click
on
this
and
the
we
should
probably
like
name
the
file
a
little
more
specific
if
I
have
a
whole
bunch
of
different
ones.
You
know
yeah
yeah,
okay,
all
right,
but
we
got
unit
tests
sleeping
right
now,
sleeping
and
doing
its
thing.
A
A
B
A
A
C
D
A
A
It
would
be
nice
to
have
a
hard-coded
value
here
of
like
what's
the
actual
text,
I
expect
from
this
thing.
You
know
what
I'm
saying
yeah
yeah
yeah,
and
so
the
font
came
up
when
we
were
talking
about
this
is
why
is
the
translation
functions?
Why
are
they
even
functional
and
unit
testing
like
we
should
probably
just
stubble
to
not
do
anything
and
just
return,
whatever
string
was
actually
passed
to
it?
A
A
I
see
what
you're
saying
the
reason
we,
the
reason
the
the
guide
suggests
doing.
This
is
because
of
jihu
gee
who's
default
context
is
not
English,
and
so
these
translation
functions
actually
run
and
their
tests
locally
fail,
because
it's
actually
doing
the
the
Translating
of
stuff
mm-hmm,
and
so
my
my
thought
is:
can
we
just
make
an
environment
that
works
on
both
our
machines
and
gee
his
machines
so
that
we
we're
not
constrained
to
you
know
what
I'm
saying,
and
we
also
can't
just
throw
like
the
other
thing
too,
is
I.
A
A
Right
on
the
test
assertion,
it'll
still
fail
on
their
machine,
see
what
I'm
saying,
because
the
other
idea
would
be
I'm,
not
gonna,
actually
edit
this
but
like.
If
we
did
yeah,
you
have
two
items:
it'd
be
nice
to
say:
I
expect
this
to
be
yeah.
You
have
funky
ideas,
you
know
whatever
the
bar
value
was
right.
A
B
C
B
A
A
The
problem
at
hand
is
like
the
production
code
runs
differently
on
different
worldwide
developer
machines,
so
the
actual
will
not
be
deterministic
if
it
runs
on
my
machine
or
if
it's
running
on
jihu
machine,
that's
seems
to
be
as
I
interpreted.
The
Rook
cause
of
the
problem
is
not
necessarily
has
to
do
with
Sprint
F,
but
more
has
to
do
with
is
not
a
deterministic
value
in
our
unit
test
land.
A
Why
is
it
machine
specific,
and
that
makes
the
assertions
fail,
because
if
there's
assertions
then
have
to
also
figure
out
how
to
adapt
to
the
machine
and
in
some
ways,
Sprint
f
is
the
most
obvious
one
in
some
ways,
it's
very
inconvenient
to
make
it
adapt
to
the
Geo
machine,
so
Mike,
my
desire
would
be
to
get
rid
of
this
requirement.
I
would
love
to
get
rid
of
the
requirement
to
have
to
translate
this
thing.
B
B
A
A
A
A
A
C
B
A
D
A
B
B
A
B
A
A
I
think
the
goal
would
be
we
as
printf
shouldn't
show
up
in
tests
at
all,
like
you
should
just
test.
This
is
the
hard-coded
string
I
expected
from
all
of
this,
and
then,
if
you
end
up
with
weird
funky
variable
names
showing
up
in
your
actuals
like
that,
should
be
glaringly
obvious,
like
you
didn't
use,
S
printf
correctly,
yeah,
yeah,
okay.
So
let's
try
it
out.
I
think
the
first
thing
to
do
is
check
out
the
Locale,
because
I
don't
even
know
where
these
things
come
from.