►
From YouTube: 99% is not enough: full test coverage and why it's awesome - Isaac Z. Schlueter @ Assert(js)
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
99%
is
not
enough,
I'm
here
to
talk
to
you
about
test
coverage.
It's
a
really
big
subject
and
I'm,
not
gonna
cover
it
fully.
Some
quick
disclaimer,
so
I'm
not
here
to
judge
anybody
I'm
extremely
unmagic
I
maintain
some
libraries
with
like
really
really
really
awful
test
coverage.
I
know
we're
all
mostly
bad
we're
you
know
do
our
best
to
improve
that's
all
we
can
do
my
goal
here
is
just
to
try
and
show
a
better
path
and
and
share
a
way
forward
and
I
know:
you're
gonna
forget
these
disclaimers
and
get
mad
anyway.
A
That's
fine
I,
just
still
felt
like
it
was
worth
saying
so
you're
here
at
a
search.
Is
you
probably
write
tests?
A
test
is
a
program
that
runs
your
code
and
it
verifies
that
your
program
does
what
you
think
it
does.
Programs
need
tests.
I
think
we
all
know
that
and
if
a
test
is
a
program,
what
tests
your
test,
usually
it's
this
lump
of
meat
in
your
head.
This
should
be
a
little
bit
terrifying.
So,
typically,
what
we
do
is
we
run
the
test
and
then
we
just
look
at
it.
A
We're
like
yeah
fine
move
on
I've,
been
writing
software
now
for
about
25
years
and
JavaScript
for
most
of
that
time,
and
one
thing
that
I've
had
to
learn
over
and
over
again,
because
I'm,
stubborn
and
dense
is
that
humans
are
terrible
at
software
and
we're
too
stubborn
and
dense
to
actually
acknowledge
this,
like
literally
just
the
other
day
I
caught
myself
thinking,
I
was
good
at
JavaScript
and
then
I
spent
three
hours
figuring
out.
Why
this
promise
wasn't
resolving
it's
cuz
I
was
calling
process.
Exit.
A
I
should
know
that
yeah
meat
brains,
meat
brains,
suck
at
this
seatbelts
seatbelts
are
good
seat
belts.
Don't
cure
diseases,
they
don't
stop
aging,
even
if
you
wear
a
seat
belt
every
time
in
a
car
eventually
and
I'm.
Sorry,
if
I'm
the
first
one
to
tell
you
this
you're
gonna
die,
that's
a
guarantee
but
seatbelts,
save
lives
and
income,
because
in
complex
dangerous
situations
we
augment
our
brains
with
technological
help,
software
it
gets
pretty
complicated.
A
Even
if
you're
doing
everything
right
there
they're
fixed
in
their
definition,
programs
are
fixed
when
we
define
them,
but
then
the
context
that
they're
in
changes,
because
we
want
to
use
it
in
a
new
way.
We
want
to
use
this
library
and
some
other
application.
So
what
that
means
is
really
there's
an
unbounded
number
of
things
to
keep
track
of,
and
complex
systems
are
always
in
a
state
of
partial
decay.
As
a
result,
coverage
is
a
meta
test.
A
It
tracks
that
what
parts
of
your
program
were
executed
by
the
tests
that
you
ran
coverage
tells
you
how
much
of
a
test
your
test
actually
is.
Basically,
it
doesn't
prove
that
your
program
is
good.
It
doesn't
prove
that
your
test
is
good.
It
doesn't
prove
that
you're,
a
good
person
or
a
competent
developer,
or
a
kind
and
loving
partner
to
your
friends
and
family.
None
of
that
all
it
does
is.
A
These
are
the
ones
that
got
executed
by
this
test,
its
verification
that
your
test
ran
your
program,
so
I
wanna
talk
a
little
bit
about
the
effects
of
exposing
costs.
A
lot
of
the
talk
around
about
TDD
or
about
other
kind
of
testing
practices
are
really
about
bringing
costs
from
later
in
the
development
process
and
pulling
them
up
to
the
very
beginning.
A
If
your
tests
are
brittle
and
they
have
to
be
updated
on
each
change
well,
then
that's
gonna
make
hundred-percent
test
coverage
really
hard,
because
they're
brittle
so
use
snapshots
you
you
know,
make
them
less
brittle,
basically
follow
all
the
good
practices
you
heard
about
today.
If
you
have
to
mock
the
whole
world
to
hit
some
buried
line
of
code,
we
could
just
not
test
no
take
that
buried
line
of
code,
put
it
in
a
separate
module,
voila,
you've
just
written
better
code,
full
coverage
isn't
about
writing
code
with
more
tests.
It's
about
writing
code.
A
That
is
more
testable,
so
there's
also
some
cases
that
I've
found
that
we're
a
little
surprising
for
me
as
I.
You
know
got
more
and
more
bought
in
on
this
idea
over
the
years.
Is
that
coverage
as
a
test
extender?
One
thing
that
was
always
a
pain
for
me
was
if
I,
if
I'm
cashing
something
or
if
I'm
memorizing
some
function
response.
A
You
know
you
got
to
use
like
some
inversion
of
control
goober
and
like
stick
in
there.
I
think
you
have
to
like
refactor
your
whole
code
base,
so
it
can
take
a
kid.
No
just
just
run
it
twice.
The
coverage
will
tell
you
if
you
hit
that
code
path
or
not
voila
less
than
a
hundred
percent
test
coverage
means
that
you
have
a
component
without
tests
means
that
you
have
some
part
of
your
code
which
is
not
being
tested.
Basically,
you
can
look
at
a
you
know.
A
Ninety-Five
percent
covered
program
as
two
parts,
it's
the
covered
part
and
the
uncovered
part
and
you're
just
using
this
module,
that's
used
without
any
tests
whatsoever.
If
you
can't
delete
it,
which
a
lot
of
times
it's
the
right
thing
to
do,
it's
a
great
way
to
get
to
a
hundred
percent
test
coverage
just
delete
all
your
code.
If
you
can't
delete
it,
then
you
should
probably
write
tests
for
it,
so
that
you
can
maybe
knows
what
it
does,
because
you're
me
brain
is
so
bad
at
this,
so
those
are
all
kind
of
like
negative
reasons.
A
What
are
some
more
of
the
positive
reasons?
Full-Coverage
actually
makes
you
look
in
the
dark
corners
of
your
codebase
it
and
that
investigation
process
tends
to
uncover
bugs
and
help
you
see
new
and
better
ways
to
design
and
implement
things.
You'll
notice,
like
oh,
hey,
we're
doing
this
in
a
really
inefficient
way
like
that
is
kind
of
dumb.
Maybe
I
should
like
make
that
better.
A
It
lets
your
meat
brain
do
what
it's
good
at,
which
is
like
creative
kind
of
exploratory
thinking,
while
the
computer
keeps
track
of
whether
or
not
you've
hit
this
line
or
not,
but
that's
all
the
boring
rational
reason
and
we
don't
care
about
boring,
rational
reasons.
We
care
about
emotions,
because
meat
brains
are
so
dumb
and
one
of
the
things
that's
really
awesome
about
tests
coverage
about
full
test
coverage
in
particular.
Is
that
going
from
like
98
percent
test
coverage
to
96
percent?
That's
okay!
Well,
we
should
probably
write
a
test.
A
It's
not
that
bad,
though,
going
from
a
hundred
percent
to
99.5
percent.
It
feels
awful
it's
so
bad.
It's
like!
Oh,
the
green
turned,
yellow
I
can't
believe
this,
oh
my
goodness,
and
that
getting
to
that
row
of
green
a
hundreds
on
the
test
output.
It's
just
like
it's,
this
delicious
high.
If
you've
never
experienced
it
I
strongly
recommend
it
a
little
bit
of
a
fair
warning,
though
it's
incredibly
addictive.
It
will
trick
you
into
being
a
develop
a
better
developer.
A
How
do
you
do
it
so
and
again
what
this
means:
you're,
just
covering
all
lines,
branches,
functions
and
statements.
Note
app
has
a
flag,
you
can
pass
in
100
and
it
will
automatically
do
this
and
fail
the
test
if
it
doesn't
have
a
hundred
percent
test
coverage.
If
you're
using
NYC
there's,
you
know
options
for
each
one
of
those
different
things,
and
basically
this
gives
you
superpowers.
Okay,
I'm
gonna
go
through
some
of
the
objections
I've
heard
mostly
on
Twitter,
but
also
in
person.
A
It
takes
how
much
time
full-coverage
does
add
up
front
death
costs,
but
it
reduces
the
amount
of
time
that
you
spend
like
arduously
going
through
and
trying
to
figure
out
bugs
and
like
oh.
Why
did
we
do
that
thing?
I,
don't
remember
and
like
all
we
needed
this
code
for
some
reason,
I
think
if
we
delete
it
it
might
break
somebody
I,
don't
know
full
coverage
exposes
that
cost
right
away
so
that
you're
not
paying
interest
on
that
technical
debt.
Oh
my
Linh
term
I
use
I
use
types.
How
many
of
you
use
typescript?
A
You
probably
don't
need
tests
right,
you're,
joking,
so
pretty
soon
after
it's
written,
if
not
before,
you
know
actually
don't
know
what
your
code
does.
The
chances
of
it
being
bug
free
are
effectively
zero,
even
with
full
coverage,
because
you're
gonna
use
it
in
a
new
context
at
some
point,
and
it's
not
going
to
work
the
way
you
think
it
does
so
test
coverage
doesn't
prevent
all
bugs
what
it
does
is
it
gives
you
the
power
to
be
able
to
fix
those
bugs
more
efficiently.
A
Well,
people
will
just
write
really
bad
tests
that
are
doing
dumb
things
in
order
to
just
get
to
100%
coverage.
Like
a
news.
Flash
people
are
gonna
write
bad
tests,
regardless
they're
gonna
write
bad
tests
with
95%
coverage.
In
fact,
they'll
probably
write
more
of
them
and
not,
and
they
won't
cover
your
whole
codebase.
The
solution
is
just
to
write
better
tests
and
to
force
yourself
to
build
components
that
are
more
testable
that
you
can
get
to
100%
coverage,
not
to
just
accept
that
some
things
are
not
testable.
I
also
find
it
really
fascinating.
A
Nobody
ever
said
to
me
on
Twitter
I've
heard
this
objection,
probably
more
than
any
other.
Nobody
has
said
to
me
on
Twitter.
Well,
I'm
gonna
write
really
crappy
tests
to
get
to
100%.
No,
it's
always
the
other
people
on
my
team,
those
dummies
yeah
they'll.
Do
it
not
me?
No
I'm,
a
good
boy.
Oh
I'd,
have
to
like
create
a
zillion
fixtures
on
four
different
operating
systems.
Simulate.
Ok,
here's
another
fun
thing
about
testing!
You
can
write!
You
can
do
some
just
like
awful
things,
some
things
that
would
make
your
hair
curl.
A
If
you
saw
them
in
production
code
like
you,
can
just
monkey
patch
the
file
system.
You
can
mock
out
the
HTTP
library,
so
it
just
like
returns
the
same
response
all
the
time.
That's
actually
a
good
thing
to
do.
There's
a
program
module
called
mutate
FS
you
can
make
it
fail.
Any
arbitrary
file
system
call,
it's
I
use
it
a
lot
only
testing
the
happy
path
is
practically
the
definition
of
works
on
mind
of
machine.
You
have
to
test
your
error
checking
code
because
your
error
checking
code
is
important.
A
You
would
use
an
untested
error
handler,
but
you
are,
if
you're
not
testing
those
code
paths.
So
what
about
things
that
really
really
cannot
be
tested
right,
like
I,
have
like
I,
have
this
function
and
it
can
it
it
tests.
You
know
if
a
is
true
else,
if
a
is
false
and
there's
no
way
that
it
could
possibly
be
one
of
those
you
know
other
than
that,
okay,
like
so
you
throw
like
you,
throw
an
error
at
the
bottom
to
be
like
this
is
untestable
all
right.
A
So
if
it's
something
like
that
and
you're
willing
to
stake
your
reputation
on
it,
I've
got
some
cheat
codes
for
you.
Istanbul
ignore
next.
If
an
else
will
tell
it
to
ignore
the
next
line,
so
you
can
still
have
a
hundred
percent
test
coverage,
but
with
an
active
declaration
that
this
little
bit
of
code
is
something
I
am
NOT
going
to
test,
because
it's
impossible.
But
what?
If
that's
not
enough?
What?
If
you
want
to
upgrade
even
more
full
test
coverage
yeah?
What
if
you're
accidentally
covered
in
things?
A
So
in
top
14,
there's
a
flag,
they're
called
coverage
map,
so
you
can
pass
it
the
name
of
a
module
that
exports
a
function
that
get
takes
a
test
path
name
and
it
returns
a
an
array
of
files
under
test
to
cover.
This
is
great
for
cases
where,
like
I,
have
a
base.
Class
and
I
want
to
make
sure
that
the
base
class
unit
test
fully
covers
it,
and
it's
not
just
getting
covered
by
like
the
test
for
other
classes
that
extend
it.