►
From YouTube: Walk through GitLab QA framework
Description
In this video, we walk through some parts of the GitLab QA framework that is used for writing end-to-end tests for the GitLab application.
A
Okay,
so
now
we
are
recording
so
go
yeah.
The
idea
is
basically
to
walk
through
not
be
whole
QA
framework,
but
to
the
last
test
that
I
wrote,
which
then
you
can
have
a
feeling
of
like
how
we
structure
our
artists
yeah,
and
we
can
also
touch
into
specific
parts
of
the
framework
like
how
we
do
with
what
we
call
resources
and
how
we
do,
how
implement
page
objects
as
well
cool.
So
let
me
start
sharing
my
screen.
A
A
A
Basically,
expecting
that
the
right
message
is
shown
in
the
end
yep,
which
is
not
ideal.
Ideally,
we
should
be
testing
the
content
of
the
file
as
well,
but
I
would
prefer
to
analyze
the
test
coverage
in
lower
levels
for
this
specific
part,
because
if
it's
already
covered
in
lower
level
tasks,
we
don't
need
to
write
comments
with
us
for
that
so
yeah,
basically,
like
our
tasks,
live
in
the
module
QA
and
then
we
described
in
the
context
the
stage
into
the
volatile
life
cycle
so
plan.
A
And
then
we
describe
the
the
feature
that
we
are
going
to
test,
which
in
this
case
is
issues
list
and
then
in
here
we
already
can
see
that
we
use
what
we
call
resources.
So
sources
I
like
if
we
think
about
like
design
patterns,
I
would
say
they
are
more
similar
to
like
factories
yep.
Basically,
so
we
can
fabricate
different
kind
of
resources
and
if
resources
can
be
projects,
groups,
issues
labels,
anything
that
you
can
create
on
users.
B
B
A
B
A
Actually,
this
is
like
Ruby
specifics,
not
really
about
the
framework.
Okay
and
I'm
not
a
ruby
expert.
Let
me
my
thinking,
but
but
what
I
remember
is
or
what
I
recall
is
that
when
it
ends
with
an
exclamation
mark,
it's
it
touches
the
I
think
the
the
class
itself
and
when
it's
not
it's
the
object,
but
I
might
be
wrong,
so
I
would
prefer
to
okay,
yeah
I'll.
Try
you
look
into
it.
A
Yeah
I'll
turn
from
the
answer
again
yeah,
so
moving
on,
then
we,
this
is
something
then
we
use
like
before
for
the
preconditions
of
the
test
when
it's
not
related
to
what
we
want
to
dust
so
like,
for
example,
what
you're
signing
first
I
want
to
create
some
issues
in
the
beginning
and
I
want
to
visit
the
specific
page
so
that
I
can
test
that
specific
thing.
One
thing
that
it's
worth
mentioning
in
here
is
that
I
don't
know
if
its
system
an
issue
but
I
think
it
is.
A
We
we
have
an
issue
which
is
just
like
we
take
screenshots
of
the
test
when
they
fail,
but
there
is
an
issue
that,
if
it
fails
in
the
before
hook
or
in
an
after
hook
or
a
before
all
or
after
all,
hook,
screenshots
are
not
taken.
So
we
try
to
avoid
using
that,
and
we
try
to
use
that
for
very,
like
for
very
stable
functionalities
in
the
best
framework,
I
would
say
so,
like
logging
in
is
very
stable
and
like
creating
things
through
the
API
that
doesn't
touch
the
UI.
A
It's
it's
more
reliable
than
things
that
go
through
the
graphical
user
interface.
So
then
we
can
do
things
inside
there
before
block.
So
in
here.
This
is
something
very
new
that
was
implemented
by
Marc,
because
in
many
different
files
we
had
to
call
two
different
lines
for
signing
mean
which
is
visiting
the
page
and
then
signing
in
with
the
adventures.
A
With
this
we
can
now
reuse
the
same
code
in
many
parts
of
the
framework,
and
there
is
also
a
method
called
signing
as
hardening
I
think
or
as
administrator
or
something
like
that
that
you
can
reuse
yeah.
Then
this
is
like
Ruby
stuff.
I
am
basically
using
the
fabricate
by
API
method
of
the
issues
resource
to
fabricate
two
different
issues
and
to
fabricate.
B
A
With
different
titles
I'm
using
this
secure
random
library,
then
with
the
project
that
I
helped
here
can
visit
the
project,
which
will
basically
go
through
that
project
URL.
And
then
we
have
a
page
object
menu
from
the
project
page,
which
has
this
method,
click
issues
which
are
basically
from
the
manual
navigate
to
the
issues
list
and
then
the
task
itself,
which
is
basically
we
describe
what
we
are
going
to
tastic,
successfully
exports
the
issues
list
as
a
CSV
and
then
I
use
methods
from
the
major
objects
to
interact
with
the
the
page.
A
So
like
we
have
index
page
for
issues
that
are
inside
projects,
and
then
this
is
something
that
is
probably
going
to
change.
I,
remember
seeing
an
issue
from
Dan
where
he
wants
to
move
more
into
the
lines
of
having
actions
instead
of
like
instead
of
having
like
click
export
as
csv,
we
could
have
like
method
that
wouldn't
be
more
descriptive.
Like
exports,
yes,
issues
list
as
a
CSV,
something
like
that.
The.
A
And
then
we
have
like
I
like
to
do
the
expectations
in
a
more.
How
could
I
call
it
in
a
more
scoped
way
in
some
tasks?
You
see
that
we
expect
the
page
to
have
something,
and
then,
in
this
case,
when
the
test
fails,
it
looks
if
we
are
looking
for
contents
like
this,
it's
difficult
to
identify
what
has
changed,
because
it
will
get
the
Dom
of
the
whole
page.
So
I
prefer
to
scope
it
better.
A
So,
like
here,
I'm
scoping
to
a
specific
element
in
the
page
to
run
my
assertion
and
then,
if
something
goes
wrong,
the
the
error
is
easier
to
debug
yeah.
So
this
is
a
good
recommendation.
I
would
say-
and
this
is
basically
it
for
this
simple
test
and
then
we
can
look
into
some
things
like,
for
example,
the
project
resource.
So
let's
let
me
so
we
have
this
QA
directory
and
inside
the
QA
directories.
We
have
another
QA
directory
tree
I'm
a
bit
weird,
but
this
is
where
the
entrant
asks
leave
and
then
we
have
specs.
A
A
It
looks
like
right,
yeah
exactly
by
stage
and
the
same
for
Enterprise
Edition
functionalities,
then
outside
of
specs.
We
have
many
different
stuffs
like
the
resources
and
the
page
objects.
I
won't
touch
in
everything
like
support
tools
and
every
everything
I
would
prefer
to
start
simple
and
then
in
another
meeting
we
can
maybe
explore
other
parts
or
someone
else
could
explore
other
parts
as
well
yeah
for
sure.
So,
in
the
resources.
A
A
And
here
is
like
the
fabricates
method:
we
have
the
fabricate
method
and
in
some
cases-
and
this
is
fabricating
a
project
through
the
UI-
it
looks
like
a
UI,
so
it
uses
the
pager
objects
to
do
that,
and
then
we
have
a
fabricate
by
an
API
which
does
it
through
the
public
API
right.
But
if
you
call
fabricate
simply
in
the
dust
file,
it
will
see.
If
the
is
there
fabricated
by
API,
it
will
use
it
first.
A
We
have.
You
have
to
define
the
API
post
body,
which
basically
is
the
body
that
you
have
to
send
to
as
a
request
when
you,
when
making
the
request
to
that
endpoint,
you
have
to
pass
some
data
in
the
body,
so
here
we
pass
the
name,
the
description,
visibility
and
other
attributes
and
yeah.
Those
are
like
the
things
that
we
are
using
in
that
specific
file.
Okay,
let
me
look
into
a
different
one
that
I
have
implemented.
A
It
has
some
other
stuff,
so
this
is
for
fabricating
labels
and
we
initialize
like
some
attributes
with
already
some
default
values,
and
in
here
yeah
we
have
like
the
API
GATT,
which
in
this
case
it's
not.
There
is
no
implementation
in
the
public
API
to
retrieve
a
specific
label.
It's
just
for
the
list
of
labels.
So
we
raise
an
error
in
this
case,
but
we
override
the
API
post
path
with
the
post
path,
defining
the
public
API,
and
here
we
define
the
post
body
as
well.
A
A
A
A
Yeah,
for
example,
in
here
in
the
issues,
show
page
objects.
We
have
this
line
in
the
end,
which
will
repent
if
there
is
an
e
page
object
as
well,
so
you
can
call
directly,
as
you
were,
calling
the
the
one-
that's
not
in
the
e
directory,
because
everything
that
is
in
there
will
be
prevented
in
this
file
here.
A
A
Ok
yeah
so
in
here,
I
am
calling
page
project
issue
show
which
is
like
the
page
module
project,
module
issue,
module,
show
page
and
in
here
I
say
show
that
related
issue,
but
actually,
if
you,
if
we
look
into
the
structure
in
here,
this
relates
issue
method
is
actually
not
on
page
project
is
in
IE
page
and
since
we
prepared
in
this
one
the
one
on
e
it
becomes
available
in
here
as
well.
This
is
what
I
was
trying
to
say:
okay,.
A
It
gets
difficult
you
to
look
into
the
files
that
are
open
when
I
am
sharing
the
screen,
but
yeah.
There
are
two
page
objects
that
we
are
using
here.
That
I
think
are
worth
looking
into.
One
of
them
is
the
menu
and
the
other
one.
Is
this
one
and
I
think
it's
worth
looking
into
them
both
because
they
have
kind
of
different
implementation.
So
let's
look
into
the
menu
first,
sir.
A
A
It
was
this
file
was
a
very
long
file
and
one
of
my
first
contributions
to
the
framework
was
actually
refactoring
it,
because
I
used
to
use
like
this
concept
of
components
that
are
that
compose
a
specific
page
that
can
be
reused,
and
this
is
basically
what
we
have
done
here.
So
if
we
go
to
project
there
is
also
a
soup
yeah,
and
in
here
we
have
very
small
files
that
implement
the
specific
functionalities
for
these
submenus,
and
then
we
can
reuse
them
and
we
can
leave
the
menu
file
like
a
shorter
and
cleaner.
A
Each
project
issues
index:
this
is
more
like
a
simpler
one.
Well,
one
thing
that
I
haven't
mentioned
in
the
other
one,
but
it's
it's
the
same
in
here
is
so
we
have
the
elements
that
are
available
in
this
page
and
we
have
the
methods
that
we
can
interact
with
this
page,
the
elements
they
are
defined
in
this
structure.
Here
we
have,
we
define
this
view
block
here,
which
passes
as
an
argument
the
file
where
this
element
is
defined.
So
if
we
search,
for
example,
for
this
file
here
and
we
look
for
assignee
link.
A
The
implementation
might
be
different
like
if
it's
in
a
view
tray
as
file.
It
will
be
more
like
a
real
attribute
in
the
specific
element
in
the
component
in
RB
files.
We
have
to
define
it
this
way
and
but
basically,
the
the
main
point
of
doing
this.
This
way
is
that
we
have
something
that
we
call
I,
think
it's
selector
check
or
something
like
that.
A
B
A
A
So
let's
go
to
first
student
known
e
is
then
you
can
see
the
difference
in
here
in
the
class
we
define
the
views
directly,
but
when
it's
inside
we
use
this
module
evolved
to
basically
have
this
inside.
It's
the
same
as
to
have
them
all
available
in
the
first
page
object,
and
not
having
to
call
the
e
module
itself.
A
So
this
is
something
that
helps
to
change
but
yeah.
Then
we
have
like
basic
implementations
that
are
that
used.
The
DSL
that
was
written
on
top
of
capybara,
so,
like
click
element,
is
defined
yeah.
This
is
actually
important
for
you
to
know
so
on
page,
nothing,
the
e,
but
on
this
one
we
have
this
base
page,
which
defines
like
various
kind
of
methods
that
can
be
reused
by
many.
Other
page
objects
right
right
like
refresh-
and
this
is
where
we
will
find,
for
example,
elements
that
was
used
there.
It's
basically
an
abstraction.
A
A
A
And
yeah
I
think
I
touched
everything
that
I
wanted,
which
was
like
the
they
structure.
This
issue
that
we
have
with
the
before
block
the
fabrication
of
methods.
We
prefer
to
fabricate
things
through
the
API
when
we
sponsors
yeah,
because
it's
faster
and
it's
a
lot
more
reliable
as
well,
and
then
we
go
to
the
point
when
doing
the
tests
so
and
can.
B
I
ask
so
for
the
first
automation
tasks
that
they're
kind
of
asking
me
to
do.
I
would
expect
that
I
would
write
these
tests
exclusively
against
the
API,
so
I'm,
not
I,
don't
think
I'm
going
to
be
using
any
of
the
UI
for
the
first
set
of
tests.
I'm
gonna
right
here
are
there.
Are
there?
Is
that
common?
Are
there
examples
of
tests
against
just
the
API
inside.