►
From YouTube: Verify:Testing Group Think Big #10 (Code Coverage)
Description
Today we think small about code coverage reports and what a minimum viable change would be to make it easier for team leads to identify code files with low test coverage within GitLab.
This is a follow-up of our Think Big #9: https://www.youtube.com/watch?v=dZLPqeWG-tw&list=PL05JrBw4t0Kq53VUOvTk3VdXN79PA0SXT&index=1
A
A
The
user
can
then
create
an
issue
to
resolve
that
uncovered
test
or
uncovered
code.
Sorry
with
a
test
which,
in
turn
would
could
auto
generate
nmr
with
a
template
for
a
test,
so
that
would
allow
a
user
to
just
within
git
lab,
apply
a
test.
Add
more
code
coverage,
never
need
to
open
their
ide
all
pretty
quickly
with
an
issue
in
nmr
all
within
the
tool
drew
ricky.
Did
I
miss
anything
there
from
our
recap
or
as
a
recap
from
last
week,.
B
No,
I
think
we
did
focus
a
lot
on
kind
of
exposing
that
page
view
like
to
have
to
have
coverage
as
and
as
a
as
its
own
top
level
entity
in
gitlab.
You
could
go
and
view
the
coverage
report
in
gitlab
for
your
project,
as
opposed
to,
I
think
now,
a
lot
of
that's
handled
by
ci
artifacts
that
get
uploaded,
and
then
people
expose
them
with
the
expose
as
keyword,
and
so
those
are
completely
essentially
external
to
gitlab.
A
B
Yeah,
I
think
that,
along
with
a
lot
of
our
features,
the
difficult
thing
is
just
storing
the
data
that
we
need.
In
order
to
make
these
reports
happen,
projects
can
have
hundreds
of
thousands
of
tests
and
hundreds
of
thousands
of
files
and
those
files
each
have
millions,
can
have
millions
of
lines,
and
so
how
are?
Are
we
going
to
be
able
to
represent
this
in
a
scalable
way
that
we
can
build
into
the
application
even
just
loading,
for
example,
the
html
reports
that
get
generated
for
the
main
gitlab
project?
B
B
B
That
should
be
a
really
helpful
sort
of
starting
direction.
To
say
you
know
we
can
you
know
we
know
we
have
this
scope
we
can
use.
I
don't
think
line
by
line
coverage.
Data
for
a
whole
project
is
ever
going
to
be
like
a
big,
crazy,
graphic
anywhere.
So,
starting
with
a
specific
scope
like
that,
I
think
would
give
us
good
direction
on
the
storage.
A
Just
dig
into
that
a
little
bit
more.
If
we
were
solving
this
for
ourselves,
what
would
be
that
use
case
say,
drew
you
added
code
and
you
realize
it
wasn't
covered
or
you
opened
a
project
that
you're
working
on
and
you
realize
there's
code
in
the
file
you've
opened
that
isn't
covered.
Is
there
a
use
case
there.
B
So
that
that
would
be
by
by
file
which
that's
like
that,
I
I
went
with
by
file
because
I
think
it's
the
it
was
the
first
thing
that
popped
into
my
head,
like
when
you're
browsing
code
in
gitlab,
you're,
usually
looking
at
one
file
or
you
know,
a
merge
request
which
is
going
to
be
a
set
of.
You
know,
30
files.
But
that's
a
very,
I
think,
a
very
common
unit
of
like
code
to
browse.
B
It's
right
now
I
think
and
ricky.
Please
correct
me.
If
I'm,
if
I've
missed
something
recently,
I
think
it
all.
The
coverage
data
comes
from
artifacts,
maybe
pipeline
artifacts,
but
still
like
an
external
file
stored
somewhere
else
with
all
the
coverage
in
it,
and
so
that
and
we
fetch
it.
You
know
four
files
and
a
merge
request
so
that
the
mechanics
are
there,
but
I
don't
think
in
a
way
that
it
makes
sense
to
scale
up
to
like
repository
browsing
yeah.
B
B
We're
really
only
looking
at
what
is
going
to
be
displayed
in
the
mrdip
view,
and
that
makes
it
challenging
to
say
that
we
can
easily
just
go
and
do
it
on
a
file
by
file
level,
because
then
we
will
be
parsing.
The
entire
cobra
tour
report.
Every
time
we
load
a
new
file
in
the
file
browser
and
that
won't
be
as
performant
as
this,
where
we
can
basically
come
up
with
a
subset
and
a
background
job
and
then
push
that
file
somewhere
and
have
easy
access
to
it,
which
allows
that
to
be
performant.
B
B
Okay,
right
so
is
it
it's
cut
down
to
the
files
involved
in
the
merge
quest?
That's
my
understanding.
Yeah
okay
max
was
here
yeah,
okay,
but
it's
definitely
not
the
full
report,
because
that's
so
we're
doing
like
some
of
that
that
scoping
already
where
he
said
you
know
we,
we
know
it's
only
these
files
so
throw
away
everything
else,
but
yeah
we.
B
Able
to
throw
away
everything
else,
I
think
that
the
hard
part
is
really
coming
up
with
that.
The
first
class
view
for
the
coverage
report
like
we,
we
would
need
to
make
like
a
new
page.
That's
like
okay,
here's
code
coverage
for
your
project
like
project
level
code
coverage.
I
think
that's
the
real
kind
of
can
of
spaghetti.
B
And
we
we
can
do
lots
of
little
things.
That
kind
of
maybe
will
add
value
to
the
way
that
people
interact
with
that
report,
but
opening
up
that
big
can
of
spaghetti
is
going
to
be
a
process,
no
matter
what
I.
I
think
that
an
example
of
something
that
would
be
small,
that
we
could
add
value
with,
would
be
to
like
reverse
tfflookup.
A
A
If
we
slimmed
that
down
even
more
and
just
said
here,
is
the
file
that
you
should
add
a
test
to
or
the
file
with,
not
lowest
coverage,
I
don't
know
what
the
right
one
thing
is,
but
just
say
here
is
the
file
that
you
can
open
up
today.
Have
some
impact,
and
then
tomorrow
this
report
might
look
different.
B
A
A
B
So
I
guess
that
depends
on
whether
we're
targeting
merge
requests
or,
if
we're
targeting,
like
the
project
view
still
right.
So
if,
if
we're
targeting
merge,
requests
prompting
people
in
the
merge
request
about
the
code
coverage
of
the
files
that
they're
working
on
would
be
important.
But
if
we're
talking
about
that
view
for
that
team
leader
director
persona,
then
I
think
that's
something
else
to
talk.
A
What
I
learned
from
the
conversations
that
we've
had
already
is
that
the
team
lead
director,
whatever
that
persona
is
cares
about
that
top-down
project
view
they
want
to
see
hey.
We
have
a
group
goal.
Where
can
we
impact
that
group
goal
developers
in
their
day
to
day
want
the
visualization
we've
already
provided
I'm
doing
a
code
review?
A
B
So
it
sounds
like
there's
a
similar
mechanism
for
both
of
those
views
where
on
we,
we
ignore
the
line
by
line.
We
don't
persist.
Anything
line
by
line
the
most
granular
granular
unit
that
we're
talking
about
is
a
file
and
we're
saying
hey.
This
file
is
no
good,
or
this.
This
file
is
good
and
this
other
file
isn't
good.
You
know
here's
a
ranked
list
by
like
thumb,
emojis
of
like
here's,
your
worst
files
and
your
best
files.
B
B
B
A
B
A
B
B
A
B
A
B
A
A
B
The
one
thing
that
always
bothers
me
when
I
was
using
code
coverage
tools
is
when
the
application
wasn't
keeping
up
with
the
changes
I
was
making
to
the
configs.
So
if
I
ran
a
thing
and
then
I
saw
the
visualization
for
the
coverage
job
that
I
ran
and
it
had
like
a
bunch
of
config
files
as
like
the
top
worst
files,
and
then
I
was
like
oh
okay,
then
I
have
to
go
back
and
like
take
the
config
files
out
of
my
ignore
them.
B
When
I'm
going
to
parse
them
and
then
I'd
run
it
again
and
then
I'd
have
to
wait
for
the
thing
to
refresh
and
process
the
results
and
then
reload
the
top
10
worst
files
and
they'd
be
like
okay.
I
don't
care
about
any
of
these
files,
I'm
going
to
remove
all
those
ones
from
the
thing
and
there's
like
this
very
lengthy
process
in
actually
getting
a
view
that
I
care
about
in
the
app.
B
And
then,
if
it's
not
in
front
of
people's
eyes
all
the
time
where,
when,
if
you're
using
a
third
party
service,
if
people
aren't
looking
at
that
a
lot,
then
it
gets
stale
right
away.
So
if
I,
if
it's
something
that
I
look
at
every
two
weeks,
every
two
weeks,
I'm
basically
going
back
in
there
and
altering
it
to
ignore
files
that
I
don't
matter
because
they're
config
or
they're
third
party,
or
something
that
just
doesn't
need
coverage.
A
Can
we
do
something
simple
like
the
if
we
were
applying
this
to
the
good
lot
project,
the
highest
percentage
of
files,
I'm
guessing
are
ruby
files
and
a
file
has
to
be
actually
is
that
work
on
lines
of
code
or
on
files
yeah,
that's
rhetorical.
Could
we
use
that
identifications
identification
and
say
that
it's
of
your
top
language
identified?
A
B
They
do
have
test
coverage.
Really,
oh
great.
I
forgot
about
that,
but
you
know
I
mean
like
there's
a
lot
of
ancillary
ruby
files
yeah
just
like
configs
and
initializers
yeah,
which
those
yeah
initializers
probably
do
so
it's
so
if
file
extension
might
not
get
all
the
way
it
might
not
allow
us
to
not
have
a
solution
beyond
that.
B
The
way
I
was
kind
of
thinking
of
it
would
be
that
we
would
pay
attention
only
to
the
files
that
are
in
the
report.
So
when
you
generate
a
corporate
report,
you
set
up
all
your
ignores
in
the
config
for
the
tool
that
you're
using
to
generate
the
report
and
then
of
the
files
that
are
included
in
your
report.
These
are
the
add
ones
and
that's
how
we
would
persist
that
data
we
wouldn't
go
looking
for
more
files,
we'd
be
like
okay
from
what
you've
shared
with
us.
C
B
B
B
I
was
thinking
about
keeping
exclusions
in
and
this
you
know,
expands
the
size
of
the
table,
but
in
the
in
the
database
base
table
as
as
like
a
different.
Essentially,
you
know
we're
talking
about
one
row
per
file,
so
every
row
has
a
path,
but
then
you
could
have
a
row
in
there
as
as
a
top
10
bad
file
or
as
an
exclusion,
and
so
no
matter
what's
running
under
the
hood
when
we're
persisting,
something
in
like
essentially
our
presentation
layer,
service
model
whatever
this
is.
B
The
idea
that
something
is
excluded
is
excluded
from
presentation
and
gitlab
not
and
not
fully
excluded
from,
like
your
actual
coverage
tool.
Yeah,
that's
how
sonarcube
works
as
well.
You
there's
multiple
layers
of
possible
places
where
you
could
go
and
exclude
a
file
or
a
line
from
being
reported
on,
and
you
can
do
it
in
the
config.
You
can
do
it
in
the
sonarqube
ui.
B
I
think
you
can
even
do
it
in
like
before
it
gets
to
the
config
as
well,
and
that
makes
it
a
little
bit
difficult
to
figure
out
when
you're.
Looking
at
your
configuration
holistically,
it's
like,
where
is
this
ignored
and
like
what,
if
you
care
about
it
again,
how
can
I
go
about
about
getting
that
back?
I'm
not
sure,
that's
a
problem
that
we
can
solve
easily.
A
C
C
Because
I'm
thinking,
if
it's
just
like,
if
I'm
the
project
owner,
if
I
look
at
just
one
project
page
and
I
want
to
see
the
coverage-
I
guess
report
for
that
project-
then
maybe
we
could
just
rely
on
the
latest
pipeline
artifact
of
the
master
branch
or
whatever
is
default
branches.
Because
right
now
we
store.
Let's
say:
master
branch
has
its
own
coverture
artifact,
so
that
coverture
artifact
will
have
all
the
coverage
formation
of
all
the
files
that
were
run
or
like
covered
in
our
spec
suite.
C
C
Maybe
this,
maybe
you
could
just
rely
on
the
line
rate
of
this
because,
like
the
whole
project
or
like
the
whole
suites
line
rate
and
then
maybe
if
a
certain
class
has
a
lower
line
rate
than
the
the
main
one,
then
maybe
show
it.
Let's
have
that
priority
like
because
this
is
like
the
moving
threshold
that
we
were
trying
to
like.
If
I
understand
it
right,
we
were
talking
about
earlier
so
yeah
and
I
think
we
have
to
show
it
per
build,
or
else
we
will
end
up
like
averaging
for
builds
coverage
again.
C
B
C
Yeah
just
a
little
bit
clearer.
We
I'm
not
because
we
parse
the
xml
on
a
background
drop
once
once
the
pipeline
flows
so
and
then
we
store
the
json
data
to
the
pipeline
artifact
table
so
we'll
just
basically
display
the
json
information
and
then
I
guess,
depending
on
the
analysis,
we
need
to
do
that.
Maybe
we
could
cache
them
into
their
own
json
column
or
data.
Maybe.
C
C
I
was
trying
to
understand
why
we
need
to
versus
data
in
the
database
now,
because
I
was
thinking
initially,
they
could
just
rely
on
the
json
information
in
our
current
pipeline
artifact,
because
that
stores
these
are
not
xml
anymore,
the
one
we
because
once
the
pipeline
finishes,
we
parse
the
xml
and
store
it
into
like
a
json
artifact,
where
it
has
the
the
coverage
data
per
file
from
the
artifact.
So
depending
on
how
we
want
to
analyze
in
the
first
iteration.
Maybe
we
don't
need
to
purchase
data
in
the
database.
C
Yet
if
it's
not
that
heavy,
if
it's
like,
based
on
the
configuration,
don't
show
this
file,
if
that's
it,
then
I
don't
think
we
need
to
purchase
anything
in
a
database.
But
if
it
gets
complex,
then
maybe
we
will
need
to
figure
out
where
to
put
that
complex
analysis
result
in
like
a
database
or
like
reactive,
cache
or
whatever.
B
So
so,
if
I
understand
you
correctly
your
pitch
for
like
the
first
step
we
could
take
to
do,
this
would
be
to
basically
where
we
are
right
now
currently
parsing
the
cobratura
pipeline
artifact.
We
would
add
a
little
bit
more
information
into
that
pipeline
artifact.
We
could
do
like
the
top
10
worst
files
in
json
file
and
then
coverage
percentage
in
a
json
blob
and
then
persist
that
into
the
existing
pipeline
artifact.
B
C
B
Do
you
think
storing
all
the
files
in
in
in
objects
like
that
would
be
too
much
like
that's
what
I'm
I'm
concerned
about
here
is,
if
we're,
and
by
storing
I
mean
writing
to
the
pipeline
artifact
file.
Do
you
think
that
having
every
single
file
on
coverage
is
too
expensive?
That's
what
I
was
concerned
about
and
that's
why
I
suggested
just
having
like
the
10
worst
ones
in
that
are
actually
getting
written.
C
C
A
I
think
if
it's
something
that's
fairly
easy
to
build
and
it's
on
a
page
by
itself,
we
would
get
feedback
from
users
that
I
want
to
access
this
page,
but
the
performance
is
just
really
slow
without
impacting
anything
else
in
the
app,
and
that
would
give
us
the
feedback
that
they
want
value
out
of
this.
They
get
value
out
of
this,
or
they
see
value
out
of
this
data.
Now
we
can
iterate
on
a
more
performance
solution,
so
that
might
be
a
great
mvc
of
build
it
on
the
fly.
A
Cool,
we
are
way
over
on
time.
Sorry
about
that
folks,
I
think
we
got
to
a
really
good
spot,
though
it
sounds
like
y'all
hashed
out
a
lot
of
the
how
this
would
get
implemented
and
found
a
pretty
mvc
approach
to
it,
as
well
as
even
some
iterations,
I
think,
within
there
and
yeah.
So
I
think
this
is
awesome
anything
else
before
we
adjourn
no
certain.