►
Description
Advanced subgraph development using Matchstick
The Graph's Media:
Twitter: https://twitter.com/graphprotocol?s=20
Instagram: https://instagram.com/graphprotocol
LinkedIn: https://www.linkedin.com/company/theg...
Website: https://thegraph.com
A
Hello
again,
everybody
and
welcome
to
the
second
episode
of
the
matchstick
mini
series,
and
in
this
episode
we
will
go
over
how
to
use
a
bunch
of
handler
functions
that
matchstick
provides
out
of
the
box
in
order
to
make
your
life
with
unit
tests
easier.
So
it's
a
lot
that
I
want
to
cover,
so
I
will
just
dive
straight
into
it
now.
A
The
first
thing
that
I
want
to
show
you
is
there
is
a
method
called
log
store
that
we
can
import
from
match
the
ks
we're
going
to
import
a
lot
of
things
from
here
log
store,
which
is
basically
a
debug
helper
method
so
over
here.
If
we
want
to
see
what
happens
in
our
store
after
we've
after
we've
ran
a
handler,
we
can
say
log
store
and
and
there
it
is,
and
that
will
just
that
will
just
dump
our
that
will
just
dump
our
store
to
the
console.
A
A
A
Maybe
we
want
to
test
that
a
given
entity
is
not
in
the
store
for
some
reason.
I
actually
know
people
that
subgraph
developers
that
really
requested
this
feature,
so
we
can
say
assert
not
in
store,
and
we
we
can.
So
we
can
say
that
a
gravatar
with
with
an
id
of
just
all
zeros
does
not
exist
in
the
store.
A
Let's
actually
let's
run
this,
and
we
would
expect
our
tests
to
pass
because
a
entity
with
that
type
and
id
does
not
exist.
Now.
Let
me
just
remove
this,
so
it
doesn't
clog
things
up,
but
if
we
say,
for
instance,
that
we
want
an
entity
with
an
id
with
with
this
id
to
not
exist,
obviously
that's
going
to
be
false,
but
let's
just
wait
and
and
see
how
it
goes
there
we
go
value
for
nc
was
found
in
the
store.
Now
this
is
a
pretty
nice
segue
for
our
next
helper
method.
A
A
A
Okay
and
we
can
actually
see
that
both
of
our
tests
pass
now
we
are
still
getting
this
error
log,
which
is
going
to
be
fixed
in
one
of
our
newest
versions.
But
what's
important
is
the
test
actually
passed
because
it
failed
because
we've
marked
it,
but
it
should
fail
all
right.
So
next
thing
is
basically
using
logs.
So
I'm
just
going
to
remove
all
of
this
and
I
will
say:
oh
no,
sorry,
I'm
just
going
to
create
a
new
test.
I
will
say
test
logging.
A
And
I
will
say:
oh
sorry,
I
will
import
the
log
function
from
match
the
ks
and
then
I'll
just
go
ahead
and
paste.
I'm
just
going
to
go
ahead
and
write
some
things
like
we
could
have
log
success,
which
is
something
like
success.
It's
just
going
to
be
a
green
message
for,
for
some
reason,
people
people
might
might
want
that.
A
A
I'm
just
going
to
run
that
and
there
we
go.
This
is
this
is
all
of
the
different
logging
levels
that
we
can
print
out
to
the
console.
If
we
need
to
debug
something,
there
is
one
more
level
which
will
actually
cause
a
critical
failure,
so
critical
failure-
like
this
add
our
callback
log.critical
just
like
that-
let's
run
that-
and
this
is
when
we
we
have
cases
where
we
absolutely
don't
want
to
enter.
This
goes
if
we
have
cases
like
that
in
our
mapping
files
as
well.
A
A
A
You
could
also
create
a
folder
called
gravity,
and
you
can
have
your
test
files
in
there
and,
if
they're
inside
there,
they
don't
even
need
to
be
called
that
way,
so
they
can.
So
we
can
say
basic
tests
basic.test.ts
right,
because
you
might
need
to
have
a
bunch
of
test
files
for
a
given
data
source.
So
let's
actually
try
that
out
beyond
test.