►
Description
Continuing our series of discussions of test coverage, code quality, etc. this week we talked about how to organize data a team may care about within a monorepo. This came out of a discussion we had with the Package Group who wanted to know test coverage for just their area of the monorepo.
A
Today
we
have
some
folks
from
engineering
productivity
and
representing
package
as
well,
who
came
to
us
with
a
problem
or
an
opportunity
around
tracking
a
team's
coverage
data
within
a
mono
repo
which
we
use
at
gitlab,
and
so
that's.
The
topic
today
is
test
coverage
of
monorepos
and
I'm
going
to
go
ahead
and
open
it
up.
So
we
can
discuss
the
problem
to
solve
there.
A
B
Sorry,
my
keys
weren't
working
so
the
the
problem.
As
I
understand
it,
is
that
we
want
to
keep
track
of
monorepo
code
coverage.
So
when
there's
multiple
teams
operating
in
a
single
project
within
gitlab,
how
can
we
give
each
of
those
teams
a
meaningful
metric
to
track
their
score
in
in
in
code
coverage
for
the
code
that
they
own?
So
if
one
team
works
in
generally
these
files
or
this
area
of
the
project?
What's
the
code
coverage
for
the
files
that
they
own,
as
opposed
to
the
code
coverage
for
the
whole
project?
C
C
Yeah
we
have,
we
have
sort
of,
I
feel
like
we
have
a
nice
spread
across
the
continuum
of
different
scenarios.
Here,
one
is
like
some
teams
operate
within
the
monorepo,
and
maybe
there
are
areas
of
the
code
base
that
they
are
commonly
looking
after
some
things
have
that,
as
well
as
a
separate
project
entirely,
and
then
some
teams
work
almost
entirely
in
a
separate
project,
which
is
a.
C
A
Okay,
I
think
that's
a
good
high
level
summary
of
the
problem.
So
if
we
continue
in
and
talk
about
who
has
that
problem,
what
job
are
they
trying
to
do?
I'm
going
to
start
out?
This
sounds
very
similar
to
in
a
previous
lifetime
working
at
a
company
that
was
in
a
monorevo
and
as
we
started
to
break
into
microservices,
my
teams
are
responsible
for
multiple
workflows
through
the
mono
repo,
as
well
as
as
we
started
to
break
things
out.
A
So
my
team
lead
would
want
to
have
seen
what's
our
test
coverage
across
the
bits
that
we're
responsible
for
both
within
those
little
projects
that
we
have
in
microservices
and
then
what
we
still
have
within
the
mono
repo
itself.
So
it
sounds
like
that's
a
use
case
or
a
person
who
would
have
that
problem?
C
C
Think
about
quality
engineers,
okay,
yeah
quality
engineers,
software
engineers
in
test
are
working
within
a
team
in
some
cases
and
they're
going
to
want
to
understand
where
to
put
their
focus
as
well.
So
it's
those
people
are
going
to
want
to
be
able
to
see
this.
I
imagine
I'd
say
that
was
one
I
think
I
don't
know.
I
don't
want
to
speak
for
anyone
here
as
a
product
manager,
but
I
wonder
about
whether
whether
product
managers
are
trying
to
help
prioritize
some
quality
work.
C
D
D
D
B
A
Yeah
and
jumping
back
up
to
the
product
managers
prioritizing
test
ricky
and
I
have
been
having
a
conversation
on
and
off.
I
think
for
about
six
months
now
about
risk-based
testing
and
identifying
workflows
through
through
the
business
cases
so
like,
if
you're
the
product
manager
for
an
ecommerce
experience.
You
want
to
make
sure
that
that
checkout
is
rock
solid,
and
so
you
might
take
a
look
and
see
hey.
What's
our
test
coverage
like
in
that
checkout
workflow?
Is
it
at
you
know,
80
or
above
versus
a
product
listing
page
you?
A
C
I
should
probably
also
mention
my
own
workflow,
my
own
job,
to
be
done.
Yeah,
I'm
mentioning
other
people
first
yeah
for
me
as
a
senior
manager.
I
have
multiple
teams
that
I'm
accountable
for
at
some
level,
and
so
I'm
interested
in
sort
of
looking
at
those
teams
and
individually
as
those
teams
sort
of
being
able
to
see
where
that
coverage
is
at
to
see.
C
If
there's
a
conversation
that
needs
to
be
had,
or
maybe
we
need
more
focus
in
that
area,
and
then
I
mean
would
it
be
great,
but
I
think
this
is
maybe
several
several
iterations
down
the
road
is
like
being
able
to
roll
that
up
into
something.
That's
absolutely
useful.
I
would
suggest
that
maybe
directors
have
the
same
need.
I
don't
want
to
speak
for
anyone
who's,
not
here,
but
I
would
be
interested
in
saying
that
you're
going
to
say
something
james,
sorry
else.
C
The
one
other
I
think,
I
think
of
is
like
delivery
team
infra,
those
the
the
sort
of
infraside
peeps.
They
probably
you
know
it
might
be
interesting
to
look
at
this.
As
part
of
you
know,
I
think
we
often
think
about
code
coverage
when
we're
say
adding
new
new
areas
of
the
app.
Maybe
there's
new
functionalities,
we're
adding
and
we
want
to
make
sure,
there's
coverage.
But
overall,
if
we're
going
to
roll
out
something
change
the
infrastructure
somewhat.
C
Maybe
we
may
be
getting
a
slice
of
that
code
and
seeing
you
know
where
the
coverage
is
at
to
determine
risk
from
an
infrastructure
standpoint.
Maybe
the
I
don't
want
to
speak
for
anyone
over
there,
but
maybe
that's
something
to
think
about
as
well.
That
might
be
different
slicing,
though
more
like
this
is
the
thing
we're
deploying
what's
the
coverage
in
this
release
yeah
so
that
release
manager,
persona.
A
A
A
C
B
Well,
that
makes
sense
too,
because
a
lot
of
the
people
well
pretty
much.
All
the
teams
at
gitlab
are
oriented
around
different
areas
of
the
product
and
different
workflows
and
different
features,
so
that
kind
of
team
slash
feature.
Alignment
makes
sense
for
for
a
lot
of
different
stakeholders
and
just
because
of
the
way
that
we
organize.
The
other
thing
I
was
thinking
about
is
like
security
engineers
or
we're
talking
about
risk
a
lot.
A
So
if
I
look
at
all
of
those
different
personas
and
all
of
the
the
different
jobs
that
we're
trying
to
do,
one
theme
kind
of
comes
across
of
we
want
to
organize
outside
of
the
normal
repository
structure
of
files
and
directories
or
groups,
even
in
projects
and
say
these
bits
of
code
in
my
mono
repo
all
organized
under
this
unit.
Whether
that
unit
is
a
team
or
a
team
of
teams.
A
If
you
start
to
roll
those
things
up
or
a
slice
of
a
release,
even
where
you
can
say
that
all
of
this
stuff
is
going
into
the
release
and
seeing
for
those
bits
of
code,
what
are
metrics,
we'll
say,
loosely
metrics,
but
we
can
niche
down
into
test
coverage,
are
associated
with
that
over
either
this
point
in
time
against
our
default
branch
or
for
this
release
or
looking
back
over
time.
Even
if
you
wanted
to
track
things
historically.
B
B
Would
it
would
it
make
sense
if
you
could
pick
if
you
could
take
a
slice
of
a
repository
and
say
this
part
of
it,
for
I
want
to
do
all
my
regular
project
and
repository
functions.
Das
asked
code
coverage,
but
I
want
to
pretend
that
it's
only
this
and
sort
of
have
have
the
smaller
slice
operate.
Exactly
like
a
full
project
would,
and
then
that
might
make
I'm
just
thinking
about.
If
you
could
pretend
that
this
part
of
your
project
was
a
whole
project,
it
might
be
easier
to
bring
over
all
that
functionality.
B
A
Yeah
that
makes
sense.
I
think
that
if
you
could
start
to
structure
things
just
by
file
you're
going
to
get
80
of
the
use
cases,
I
think
there's
cases
where
different
like
you're,
going
to
have
multiple
workflows,
that
all
use
the
same
bits
of
code,
so
they're
going
to
try
to
reuse
or
use
the
same
file,
which
you
could
probably
do
or
only
use
parts
of
a
file
where
that
breaks
down.
But
that's
probably
in
the
long
tail.
B
Is
it
kind
of
leads
you
down,
or
at
least
it
leaves
my
brain
down,
a
path
of
where
I'm
running
duplicate
pipelines
and
that's
not
something
that
I
want
to
get
into
because
that'd
be
pretty
inefficient
and
it
would
cost
money
to
do
so.
I
I'd
be
thinking
about
well.
How
can
we
break
down
these
reports
by
file
a
little
bit
and
then
associate
those
chunks
of
files
with
a
label
or
a
group
or
a
collection
of
some
sort?
A
generic
collection.
A
Cool
before
we
think
too
small
on
that,
let's
keep
thinking,
big
and
think
about
for
our
vp
or
director,
personas
or
team
lead
personas.
What's
the
ideal
outcome,
look
like
for
them?
What,
at
the
end
of
the
day,
did
they
get
if
they
can
start
to
organize
by
file
thinking
more
about
the?
What
than
the.
B
How
I
think
I
think
that
depends
on
what
the
end
result
is
because
I
know
we,
like
you,
said
we're
talking
about
this
risk
dashboard
a
lot.
I
think
that
would
be
really
great
to
have
that
single
number
rolled
up
and
that's
kind
of
the
opposite
of
what
we
want
to
do
right
now,
where
we
want
to
kind
of
have
these
more
fine-grained
points.
B
I
think
that
that
would
help
the
vp
director
personas,
like
dan,
was
saying
when
they're
talking
with
their
direct
reports
about
their
performance,
that's
another
metric
that
they
could
introduce
to
those
conversations.
So
that's
like
hey.
I
noticed
that
for
your
team's
area,
the
code,
the
code
coverage
is
much
lower
than
the
average
what's
going
on
there
so
like
that,
that's
a
good
trigger
for
that
type
of
conversation
to
to
have
with
data.
C
A
C
Yeah
that-
and
I
think
we
were
talking
a
little
bit
about
it
before
what
we're
saying.
If
I
can
look
at
that
data,
I
would
agree
with
ricky
in
general
that
I'm
going
to
be
saying
hey,
you
know
we
have.
These
targets
target
is
80
percent
of
whatever
it
is.
I
forget
right
now,
but
the
target
is
x
you're
at
why?
How
do
we
make
it
x,
type
thing?
C
C
The
team
lead
the
manager
to
be
able
to
work
on
that
themselves
without
having
you
know,
senior
manager
slash
director
coming
along
going
hey,
what's
up
with
this
number
right,
and
so
that
would
be
important
for
the
it
to
be
self-service
and
and
single
source
of
truth
type
thing
of
being
on
enabling
ems
to
you,
looking
at
the
number
and
going,
I
need
to
adjust
this.
How
do
I
check
in
on
that?
A
Sure
so,
then,
breaking
that
down,
we
talked
about
like
the
senior
manager.
The
director
is
going
to
want
to
see
that
rolled
up
by
the
teams.
The
team
lead
obviously
is
going
to
want
to
see
that,
but
at
the
end
of
the
day
we
want
to
enable
developers
to
act
on
that
data
quickly
easily
as
part
of
their
daily
workflow.
So
what
does
that
potentially
look
like?
How
does
our
scott
drew
and
eric
gonna
know
they're
contributing
to
their
team
goal
of
increasing
coverage
of
their
area
by
five
percent?
This.
D
I
think
it'd
be
nice
if
we
we
had
like
the
chart
of
what
our
team's
test
coverage
is,
what
our
historical
test
coverage
has
been
and
maybe
tied
in
with
other
metrics
that
we
have
such
as
the
number
of
bugs
our
team
has
has
had
in
the
past.
So
as
our
test
coverage
has
gone
up,
are
we
actually
lowering
our
bugs?
D
B
I
think
what
the
longer
we
talk
about
these
these
types
of
problems.
We
often
go
back
to
that
kind
of
holistic
dashboard
where
it'd
be
nice.
If
we
could
see
everything
that
is
about
like
the
metrics
for
the
code
for
our
individual
slice,
we
want
the
code
quality.
We
want
the
sas
stand
with
the
dash
scans,
the
bug
issues.
We
want
all
that
stuff
on
one
page
where
we
can
kind
of
go
and
see
the
stats.
C
You're
also
going
to
want
to
know
what
the
target
is.
So
that's
something
important
you
know
I
don't
want
to
for
people
writing
regularly,
but
from
my
perspective,
I
want
to
see
where
the
target
is
and
how
far
off
and
where
the
trend
line
is.
So,
if
we're
trending
up
and
we're
pretty
close,
I'm
not
going
to
be
stressed
about
it.
C
A
I've
also
talked
about
different
targets
for
different
areas
of
the
code.
Where
you
talk
about
riskier
code,
you
want
a
higher
test
coverage
value.
Less
risky
code
doesn't
need
as
much
much
test
coverage,
so
you
might
want
to
break
it
down
that
way
and
say
high
risk
code.
We
want
it
80
medium
risk,
60,
whatever
it
might
be
and
start
to
drill
down
into
that
as
well
as
well
as
then
setting
thresholds
potentially
of
if
you're
working
in
a
high
risk
area.
Your
mr
can't
let
the
test
coverage
threshold
get
below
75.
A
C
C
I
think
from
I
was
just
as
you
were
saying
that
I
was
thinking
about
the
practice
of
writing
code
and
writing
tests
and
how
we
go
about
doing
that
and-
and
I
think
that's
one
of
the
other
ways
that
I
might
interpret
editions
of
code
without
you
know
that
detract
from
our
overall
coverage
percentage
is
why
we're
ending
up
not
actually
writing
tests
as
part
of
our
code
and
covering
our
area.
What
what's
contributing
to
that?
C
So
this
that
element
of
analysis
that
I've
kind
of
been
doing
as
well,
I
think
is
pace-
is
where
oh.
This
is
a
you
know
some
area
where
we
have
to
get
it
out,
we're
going
to
skip
this
because
it's
a
prototype
or
whatever
it's
behind
a
feature
flag
or
whatever,
maybe
there's
explanations
that
makes
it
general.
I
wouldn't
want
to
be
seeing
people
adding
code
without
test
coverage.
That
would
be
like
just
very
good
conversation.
A
A
C
Yeah
I've
started
calling
this
git
lab
over
the
time
by
the
way,
once
we
go
past
the
five
minute
to
go
mark.
This
is
good
for
the
time
and
I
would
say
to
answer
the
question.
I
think
I'm
always
thinking
about
how
our
integrated
solutions
can
contribute
to
offering
great
great
products
to
our
customers,
and
so
that
means
how
we,
how
we
actually
integrate
this
data
in
a
way,
that's
helpful.
C
I
think
splitting
across
multiple
different
axes
of
information
can
be
really
valuable
here,
because
we
have
access
to
everything
in
theory,
so
being
able
to
have
a
different
view
for
a
release
manager
or
something
like
that
is
something
that
might
be
pretty
pretty
interesting,
but
also
integrating
it
in
pipelines
and
doing
all
sorts
of
stuff
like
that
could
be
really
cool.
I
think
that's
a
pretty
generic
answer
so
I'll
leave
it
at
that
yeah.
A
I
think
this
organization
idea,
though,
of
saying
all
of
these
chunks
of
files,
are
this
new
logical
thing
and
being
able
to
apply
all
of
the
different
lenses
to
that
so
saying.
Here's
code
coverage.
Here's
code
quality,
here's
whatever
else,
you
want
for
this
release
the
files
that
have
changed
in
this
release.
Here's
how
those
metrics
look
compared
to
the
last
release
that
we
did
or
compared
to
all
of
the
default
branches,
that
these
projects
are
shipping
same
thing
for
monitoring
of
here's,
what
it
looks
like
in
production:
here's
how
it
looked
before.
C
Well,
we're
also
started
talking
about
only
running
this
for
code
that
can't
change
to
limit
the
time
it
takes
to
run
testing
right,
and
so
this
could
align
pretty
well
with
that,
as
at
the
same
time,
right
just
to
be
integrated.
Here's
a
differential
test
run
differential
coverage
change,
those
sorts
of
things
yeah.
B
As
as
we
get
better
with
that
running,
very
specific,
like
running
tests
for
changes,
there
could
be
a
a
cool
integration
where
it
dumps
you
right
back
into
the
web
ide
and
says:
hey,
there's
no
coverage
here,
you
just
added
you
added
some
code
here
that
doesn't
have
a
test.
This
is
where
all
the
other
tests
are
click.
Here
you
go
right
back
into
the
ide
and
write
your
test,
save
run.
C
A
B
A
C
B
A
B
A
B
A
Drop
peeps.
Thank
you
very
much
all
right
thanks
dan.
That
was
an
excellent
think,
big,
thank
you,
everyone,
ricky
and
dan,
who
just
left.
Thank
you,
as
always
for
taking
notes
for
me,
because
I
never
do
next
week,
we'll
have
our
think
small,
taking
this
down
to
a
super
small
nbc
that
we
can
implement
in
an
upcoming
milestone,
so
we'll
be
thinking
big
or
thinking
small
next
week.
All
right
thanks!
Everybody
cheers
thanks,
take
care.