►
From YouTube: JavaScript: A Test - Richard Young
Description
This will be a practical approach to testing both browser and server JavaScript code. We will look at how to set up a testing framework for your project as well as some of the types of tests you will be likely to write.
We will touch on testing components, APIs, mocking, snapshot testing and even how to approach that horrible piece of jQuery code that lives in a dark corner of your code base.
This talk was recorded for the Jozi.JS meetup on 22 March 2018.
https://www.meetup.com/Jozi-JS/events/248463266/
Disclaimer: The opinions in this talk are those of the individual and do not necessarily represent those of this channel, the meetup group, or it’s sponsors.
A
Hello,
everybody.
Can
everyone
hear
me?
It's
quite
a
small
group
today,
there's
no
microphone,
but
hopefully
everyone
can
hear
me
so
my
name
is
Richard
I
work
for
a
company
called
binary
and
you
can
find
me
on
github
and
Twitter
under
Richard
Young,
zero,
zero
and
today
I'm
going
to
be
talking
about
unit
testing
in
JavaScript.
This
is
also
the
only
slide
that
I
have
so
the
rest
of
this
talk
is
going
to
be
quite
informal,
we're
going
to
be
looking
at
a
lot
of
code
and
we're
going
to
go
through
stuff
quite
quickly.
A
A
Anyone
heard
of
Ava
it's
quite
new,
but
one
of
the
big
things
with
Jason
ava
is
that
they've
got
very
good
sandbox
environments
for
running
each
test
and
they're
also
really
good
at
running
tests
in
parallel.
So
there's
loads
of
stories
online
where
people
have
taken
their
testing
suite
down
from
like
30
minutes
to
like
11
seconds,
and
maybe
not
that
much.
But
anyway,
it's
pretty
good.
Like
you
know,
people
are
getting
some
pretty
positive
things
out
of
these
two
libraries
Geist
is
actually
built
off
of
maca.
A
That's
pretty
much
got
maca
and
Jasmine
and
Carmel
all
built
into
it
as
one
package.
So
you
don't
have
to
go
and
configure
these
things
yourself.
Ava,
on
the
other
hand,
is
designed
to
be
written
pretty
much
from
the
ground
up
as
something
new.
It
also
does
some
really
cool
stuff
with
parallelism
and
async
stuff,
but
today
I'm
gonna
focus
mainly
on
just
because
it's
the
easiest
way
to
get
going
with
testing
stuff.
A
It's
got
everything
that
you
need,
Bolton,
you
don't
have
to
configure
anything
and
you
can
do
most
of
the
things
out
of
the
box
with
just
so.
What
we'll
do
is
we'll
go
through
a
couple
of
examples
of
we'll
start
with
how
it's
set
up
just
in
a
project
and
then
we'll
look
at
some
examples
of
things
that
we
might
want
to
test
cool.
So,
let's
start
off
with
we've
got
a
project
here,
npm
project.
A
It's
got
a
very
simple
function
in
one
javascript
file
called
sum
which,
as
the
name
implies,
returns
the
sum
of
the
the
two
parameters.
If
we
wanted
to
write
a
test
for
this
using
just,
how
would
we
get
started?
So
if
we
take
a
look
at
our
package,
like
jason,
we've
got
absolutely
no
dependencies
at
the
moment.
So
the
first
thing
we're
probably
going
to
want
to
do
is
we're
going
to
want
to
install
just.
A
Cool
this
usually
can
take
a
little
while
because,
like
I
said,
it's
dependent
on
quite
a
lot
of
different
things.
So,
while
that's
busy
installing
we
can
start
by
creating
our
first
test
file,
the
convention
for
naming
test
files
in
jest
is
usually
you
would
say
whatever
the
file
is,
that
you're
testing
dot
test
is
so
in
this
case
we're
testing
the
index
file.
So
it's
just
going
to
be
index.
Dot
test
is
just
picks
up
these
files
automatically.
A
If
you
don't
want
to
use
that
naming
convention,
you
can
put
it
inside
a
folder
called
underscore
underscore
tests
underscore
underscore
if
you're
willing
to
go
to
that
much
effort
to
do
it,
then
you
can
do
that,
but
I
personally
just
prefer
to
write
test
ojs,
and
you
can
put
that
file
anywhere.
You
want
and
just
will
pick
it
up
automatically.
A
A
Okay,
while
that
is
installing,
let's
move
on
alright.
So
if
we
want
to
to
write
our
test,
the
first
thing
that
we'd
have
to
do
is
we
obviously
have
to
get
some
sort
of
a
handle
on
the
the
function
that
we
want
to
test
right.
There
we
go
so
hopefully
that's
added
our
dependency,
that
it
has
cool
to
run
jest
we're
going
to
need
some
sort
of
a
script.
A
A
Can
I
get
a
handle
on
that
and
to
write
our
test
very
similar
to
maka?
Most
of
you
seem
to
know
maka
we're
going
to
give
it
a
going
to
write
a
test
function
that
takes
in
two
parameters.
The
first
one
is
the
name
of
the
test,
so
I'll
just
say
adds
1
plus
2
to
equal
3,
and
the
second
parameter
is
going
to
be
the
function
that
actually
runs
the
test.
A
So
if
you're
familiar
with
maka
I
think
it
uses
it
instead
of
instead
of
test
and
I'm,
not
sure
if
it's
required,
but
you'd
usually
have
a
describe
wrapping
your
your
test
functions
inside
maka.
You
can
do
that
inside,
just
if
you
want
to,
but
it's
not
required,
it's
just
kind
of
a
way
of
scoping
your
test.
If
you
want
to
add
more
information
to
it,
but
by
default
just
will
scope
it
according
to
the
file
cool.
A
Cool
so
a
dren,
we
can
see
that
one
pick
one
test
passed
and
it
gives
us
a
nice
output
about
which
tests
actually
passed
in
the
name
of
the
test
that
we
gave
it
all
right.
So,
in
terms
of
IDE
support,
webstorm
supports
jest
in
some
of
the
newer
versions.
You
might
have
noticed,
there's
a
little
icon
in
the
gutter
over
there.
That
allows
us
to
run
the
test
and
Visual
Studio
code
also
has
a
really
nice
add-on
for
jest
that
works
just
by
installing
the
add-on
works
out
of
the
box
cool.
A
A
No,
it
doesn't
run
and
the
area
that
we're
getting
is
unexpected
token
import.
If
you
ever
try
to
use
Babel,
you
might
have
encountered
that
a
few
times
so
just
does
support
Babel
and
transpiling
your
code,
but
what
it
requires
is
it
requires
you
to
at
least
kind
of
tell
it
what
version
of
JavaScript
we're
targeting,
because
I
mean
it
could
be
typescript,
it
could
be
es6.
It
could
be
year,
seven
whatever
you
wanted
it
to
be,
so
we
need
to
at
least
give
it
some
sort
of
a
config
to
let
it
know.
A
What
are
we
writing
this
javascript
in,
so
all
we
really
need
to
do
is
give
it
a
babel,
config
and
we're
going
to
be
using
something
called
babel,
preset
env.
Anyone
use
that
before
it's
quite
a
cool
thing.
What
it
will
do
is
try
and
pick
up
what
syntax
you're
using
and
automatically
transpile
it
down
to
something
that's
used
by
most
browsers.
A
It's
one-
hopefully
we
won't
take
as
long
so
now
we
haven't
actually
installed
Babel
as
part
of
our
project
yet,
but
because
it's
Bolton
as
part
of
gist
and
it's
picked
up
that
we've
put
in
a
babel
config,
it's
not
going
to
be
able
to
use
that,
and
hopefully
you
will
be
able
to
run
our
tests
using
year.
Six.
A
Cool
and
our
test
now
passes.
So
what
happens
if
we
want
to
use
tap
script
with
us?
So
there's
a
library
called
TS
chest
which
does
all
of
this.
For
you.
It
hooks
up
your
source
maps
so
that
you
can
see
all
of
your
areas
and
everything
inside
typescript.
It's
quite
easy
to
set
up
it's
just
a
couple
of
lines,
but
if
you
wanted
to
use
typescript,
you
can
do
that
quite
easily
with
just,
and
it's
quite
well
documented.
A
Two
other
features
that
I
just
want
to
show
you
quickly
with
chest
is
we
can
also
do
we
can
pass
through
a
parameter
watch
to
the
underlying
just
come
on.
So
that's
what
the
the
double
set
of
double
dashes
is
doing
is
just
passing
that
parameter
through
to
the
underlying
command,
so
we're
essentially
running
just
watch,
and
this
will
start
chest
up
in
watch
mode.
A
Watch
mode
is
quite
intelligent
in
terms
of
it'll
only
run
tests
on
files
that
have
changed
so
each
time,
a
file
changes
that
will
pick
up
which
files
have
changed
and
which
tests
are
affected
by
that
and
only
run
that
subsection
of
tests.
So
you
can
keep
this
running
in
the
background
without
having
to
worry
about
what
it's
doing
and
it'll
constantly
give
you
feedback
on
whether
you've
perhaps
broken
something
in
another
part
of
your
code
cool.
So
if
we
go
to
function,
we
change
that
to
a
instead.
A
A
A
All
right
cool
so
in
this
test
over
here
we're
using
a
function
or
helper
called
to
be,
and
this
comes
off
of
the
matches
that
are
built
into
jest.
What
this
does
is
it
delegates
to
the
function
object,
art
is:
does
anyone
know
what
that
does
it's
pretty
much
the
same
as
as
your
equality,
if
it's
a
primitive
datatype,
but
we'll
check
if
they're
the
same
value?
If
it's
an
object,
two
checks,
if
it's
the
same
object
reference
in
memory,
so
that
obviously
doesn't
help
us
if
you
want
to
start
testing
more
complex
objects.
A
So
let's
take
a
look
at
another
example.
Here,
we've
got
a
function
called
add
total,
which
takes
in
a
price
list,
and
the
idea
is
that
the
price
list
just
has
a
list
of
items
with
numerical
values.
We
want
to
add
up
all
of
those
values
and
it'll
put
a
total
onto
that
same
object
for
us.
So
the
test
for
this
I'll
just
go
through
it
is:
we've
got
a
price
list,
for
example
with
eggs,
milk
and
bread.
We
want
to
say,
add
total
and
we
now
expect
the
result
to
be
the
same
thing.
A
But
it's
got
an
added
total
on
it,
which
is
now
everything
added
up,
so
we
can't
use
to
B
because
it's
objects,
so
what
we
can
use
is
another
match
of
Bolton
suggests
called
to
equal,
and
this
is
essentially
a
deep
equals.
It's
going
to
take
each
item
on
our
object
and
if
it
is
an
object,
it's
going
to
recursively
go
in
there
and
then
check
each
item
on
that
one.
It's
going
to
keep
going
and
check
that
everything
on
the
object
is
is
the
same.
A
It's
essentially
the
same
as
a
lot
of
people
will
do
like
a
object
but
string
if
I
weighed
over
Jason
and
string
if
I
and
then
pause
it
again
to
create
a
deep
copy.
It's
kind
of
like
that,
but
that's
a
it's
a
little
bit
more
efficient,
I.
Think
than
that
all
right
cool.
Let's
just
check
that
this
test
runs.
A
A
A
A
In
array
containing
wait
until
the
next
example
and
see,
you'll
never
believe
what
happens
next,
all
right
so
so
as
Jerry
alluded
to
this
is
also
very
useful
for
for
testing
subsets.
If
we
only
care
that
there's
one
or
two
elements
in
that
array
array
containing
that's
pretty
much
think
of
it
as
like
looping
through
the
items
and
checking
that
that
item
is
contained
inside
the
array.
So
this
should
work
and
so
I
should
this.
A
Okay,
so
this
array
containing
is
quite
useful,
but
something
that's
even
more
useful
is
we
can
do
the
same
sort
of
thing
with
objects?
There's
a
another.
Matcher
called
objects
containing.
So
when
we're
busy
comparing
objects,
if
we
only
care
about
one
or
two
items
on
the
object,
we
can
use
the
expect
objects
containing,
for
example,
here
we
only
care
that
a
and
B
have
got
that
value.
C
can
be
absolutely
anything.
We
don't
care
about
it.
A
The
real
power
of
matches
the
comes
in
combining
them
together
so
over
here
we've
got
an
input
array
and
in
this
array,
are
a
list
of
objects,
and
each
object
has
a
name.
What
we
want
to
look
for
is
we
want
to
look
for
objects
inside
this
array
that
contain
the
name
Wally
like
from
Where's
Wally.
That's
the
thing
right
so
here
what
we
can
use
is
expect
inputs
to
contain
equal,
it's
to
contain
equal
and
not
to
contain.
A
A
A
A
Yep
exactly
so,
what
happens?
Is
we
start
off
some
asynchronous
code
which
goes
off
and
does
something
our
test
carries
on
and
completes
and
by
the
time
this
code
returns
to
us?
Our
test
is
already
done.
It
doesn't
know
what
the
result
is,
because
this
thing
has
already
gone
off
and
done
whatever
it
was
doing.
So
here
are
three
examples
of
things
that
we're
going
to
look
at
how
we
would
test
a
successful
promise,
unsuccessful
promise
and
a
callback.
A
So
if
we
look
at
the
the
successful
promise
first,
that's
quite
easy
for
us
to
just
say
that
we
expect
the
successful
promise
dot
resolves
to
be
success,
that
dot
resolves
that
comes
from
jest
is
actually
just
syntactic
sugar
for
doing
dot,
then
and
then
taking
the
value
and
passing
it
to
the
next
function
along
the
line.
But
it
makes
it
quite
easy
to
read
as
a
human
to
know
exactly
what's
happening
with
that.
A
A
Let's
chat
afterwards
so
I've
tested
observables,
it's
a
little
bit
more
complicated,
we'll
use
the
last
item
on
this
list.
It's
similar
to
callbacks
all
right
cool,
so
unsuccessful
promises,
as
you
may
have
guessed,
is
very
similar.
We're
just
going
to
say,
dot,
rejects
and
make
sure
that
whatever
it's
rejecting
with
is
the
right
value.
In
this
case
it's
fail
and
now
callbacks.
So
callbacks
are
a
little
bit
different
right.
We
don't
really
have
a
way
of
being
able
to
say
dot,
then
or
kind
of
wait
for
a
callback
to
return.
So
what
Jess
does?
A
Actually
what
Jess
stole
from
maka
is
another
way
to
write
your
test
where
it
takes
in
an
argument
called
done
and
done
is
a
function
that
we
will
call
at
some
point
during
our
test
and
we're
pretty
much
saying
the
test
is
not
done
until
we
say
sorry.
So
what
what
happens
is
if
the
done
function
is
not
called
within
five
seconds.
The
test
will
fail.
That's
obviously
quite
a
high
amount
of
time.
If
you
have
a
thousand
tests
that
are
taking
five
seconds
to
fail.
A
It's
not
good
for
how
long
your
your
test
suite
is
going
to
take
to
run,
but
there
isn't
really
another
way
to
do
it.
We
can
fiddle
with
that
time
ID
if
we
want
to.
If
we
know
that
it's
going
to
be
quite
quick,
we
can
move
it
down
to
like
two
seconds
or
one
second,
but
essentially
we
have
to
implement
that
callback,
and
once
the
callback
has
done
its
assertions,
we
can
then
call
down
on
it.
A
Because
it
took
five
seconds
to
start
the
test
and
then
5
seconds
to
timeout
alright
cool,
so
we
can
see
that
it
timed
out
like
that,
so
with
observables.
You
have
to
use
something
similar
to
this.
Additionally,
what
you
have
to
do
is
you
have
to
you,
have
to
tell
it
to
expect
certain
assertions.
So
what
we
could
do
here
is
I
think
it's
I
think
it
might
just
be
expect
to
surgeons.
A
I
can't
remember
the
exact
syntax
but
you're
pretty
much
telling
it
that
we're
going
to
do
at
least
one
assertion
inside
this
test,
and
if
you
don't
get
to
that
assertion
and
you've
gone
through
the
whole
test,
then
you
should
fail
so
by
default.
If
you
don't
do
any
assertions
in
a
test,
it
just
runs
through
and
passes.
We're
telling
it
to
look
for
an
assertion.
A
A
A
A
You
might
have
to
just
let
me
know
when
that
happens,
so
I
can
fix
it.
Okay,
so
X
EOS
is
quite
popular
for
making
Ajax
calls
we're,
making
a
get
call
to
that
URL
and
we're
doing
some
kind
of
processing
with
the
response
cool.
So
if
we
wanted
to
to
test
something
like
this,
we
wouldn't
really
want
to
be
making
that
call
to
that
URL
because,
like
I
said
time
consuming,
we
don't
know
we're
not
in
control
of
whatever's.
A
A
A
Then
what
we're
going
to
need
to
do
is
we're
going
to
need
to
tell
just
that
when
we
call
get
on
Axios,
we
want
to
mock
the
resolved
value
and
that's
what
we
wanted
to
return.
Instead,
if
it
wasn't
a
promise,
this
is
returning
a
promise.
It
would
be
mock
return
value
instead
of
mock
resolved
value.
So
it's
just
sort
of
syntactic
sugar
for
saying
we
want
a
promise,
that's
going
to
resolve,
rather
than
a
promise
that's
going
to
reject
and
when
it
resolves
give
us
that
data.
A
A
That's
essentially
a
mock
inside
inside
jest
if
we
wanted
to
tell
it
to
have
a
certain
implementation,
we'd
pass
that
through
as
a
parameter.
So
we
could
say
the
implementation
of
this
is
actually
that
you
know
that
that's
implementation,
but
it's
still
a
mock
object
and
mock
objects,
are
quite
powerful.
I'll
show
you
at
the
end
of
this,
some
of
the
other
cool
things
we
can
do
with
mocks
all
right
cool.
So
then
we
can
do
an
assertion
on
on
the
return
value
and
we
obviously
expect
it
to
be
Chuck.
A
A
A
Sign-On,
yes,
there
we
go
sign-on,
does
it
alright,
so
I,
don't
know
which
one
of
those
things
jest
is
actually
using
under
the
hood
like
I
said
it
depends
on
all
of
them,
so
it
might
be
using
a
combination
of
them.
But
here
what
we
can
do
is
we
can
say
that
we
expect
Axios
gets,
which
is
the
function
to
have
been
called
with
and
then
give
it
parameters.
So
here,
what
we're
doing
is
we're
kind
of
asserting
that
our
mock
was
actually
called
with
certain
parameters.
Now
that's
really
powerful.
A
Okay,
so
who
has
used
Express
yeah,
quite
a
few
of
you,
so
this
should
look
not
this.
This
should
look
a
little
bit
familiar
we're
setting
up
a
very
basic
Express
app
and
we're
saying
that
we
want
to
get
on
slash
users,
which
is
going
to
return
us
and
a
JSON
object.
Where
name
is
Chuck
Norris
feel
like
people
have
stopped
Chuck,
Norris,
jerks
I'm,
quite
sad
about
that.
So
how
would
we
test
something
like
this
I
mean?
A
A
Good
answer:
what
most
people
try
and
do?
Is
they
try
and
extract
the
logic
into
like
another
function,
away
from
Express
and
try
and
test
that
function
in
isolation
and
then
just
leave
Express
to
do
it?
It's
that
stuff,
but
using
super
test
is
actually
a
really
easy
way
to
test
api's
quite
quickly.
So
super
test
will
spin
up
a
very
fast,
very
small
test
instance
of
our
express
app
you
can
see
over
here.
I'm
importing
requests
from
super
test.
A
I'm
then
passing
at
the
app
which
I've
imported
from
the
index
file,
and
it
then
gives
us
a
way
to
call
our
rest
endpoints
off
of
that.
So
we
can
then
say:
get
slash
user,
get
a
response
from
that.
That
returns
a
promise,
so
we're
going
to
use
async
awaits
again,
and
then
we
can
run
our
assertions
on
that
response
and
it's
quite
easy
for
us
to
test
very
simple
API
stuff.
So
a
super
test
also
has
a
number
of
other
very
powerful
things
built
into
it,
like
cookie
storage.
A
So
you
can
test
your
your
persisted
sessions
as
well
as
authentication,
and
it
even
has
the
ability
to
simulate
like
multi-part
uploads.
You
can
test
uploading
files
to
your
endpoint
without
ever
actually
needing
to
upload
a
file
to
it.
A
couple
of
caveats
to
think
about
when
using
super
test
is
it's
actually
spinning
up
an
instance
of
your
app
right?
A
It
just
so
happens
that
Express
is
quite
lightweight,
but
if
you
happen
to
have
lots
of
middle-way
on
your
your
Express
app
and
it
takes
a
long
time
to
start
up,
your
test
is
going
to
take
a
long
time
as
well.
It
is
possible
to
kind
of
split
out
your
middle
way
or
test
your
middle
way
individually,
so
that
you
don't
have
to
have
everything
start
up
all
at
once.
The
other
thing
is
that
it
starts
it
up
on
a
port
that
it
chooses.
I,
think
it's
like
50,001,
but
just
runs
your
tests
in
parallel.
A
So,
if
you're
running
multiple
of
these
tests
at
the
same
time
and
it's
starting
up
different
instances,
they're
going
to
start
clashing
on
that
port,
you
can
override
that
port
and
kind
of
just
make
it
difference
on
each
one.
But
it's
just
something
you
need
to
think
about
when
you're
using
super
test.
This
is
kind
of
more
of
an
integration
test,
so
you're
not
going
to
have
a
huge
number
of
these
tests,
but
it
is
a
really
easy
way
to
test
your
APRs.
A
Yeah,
so
so
it
definitely
is,
I
mean
if
we
take
a
look
at
this
this
index
file
over
here.
Let's
say
that
this
function
called
a
database
and
then
return
the
value
from
that
database
from
our
test.
We
can
inject
mocks
into
this
index
file
over
here,
so
we
could
mock
out
the
database
and
then
call
super
test,
and
then
it
would
then
fetch
data
from
our
mock
database.
A
All
right
cool,
so
so
most
of
what
we've
done
so
far
has
been
pure
Java
Script.
We
haven't
interacted
with
the
Dom
very
much,
but
that's
not
what
Java
Script
is
for
Java
Script
is
for
interacting
with
the
Dom
at
least
that's
what
most
people
use
it
for
so
I'm
going
to
show
you
a
quick
example
using
react.
The
same
thing
applies
to
all
of
the
other
frameworks,
I'm
just
most
familiar
with
react.
A
So
that's
why
I
made
the
example
in
react,
but
you
could
do
this
with
angular
and
view
and
any
other
component
based
program
as
well
cool,
so
just
by
itself.
People
often
think
that
just
is
a
react.
Testing
framework
I'm,
not
sure
where
that
came
from,
probably
because
the
Facebook
team
maintains
it,
but
it
was
never
designed
to
be
a
react
or
anything
it's
completely
framework
agnostic,
although
all
of
the
examples
are
written
in
react,
that's
probably
just
because
it's
a
Facebook
team,
but
you
can
you
can
test
pretty
much
anything
on
it.
A
A
Very
simple:
it's
just
going
to
render
my
components
and
my
components
has
got
an
input
box
which
is
going
to
capture
somebody's
name.
It's
got
a
button
and
when
we
click
that
it's
just
going
to
say
hello
and
it's
going
to
print
out
hello,
whatever
name
you've
put
in
there,
so
I'm
running
this,
this
application
with
parcel
as
anyone
used
parcel
it's
kind
of
like
an
alternative
to
web
pack.
A
Alright
cool,
so
here
is
our
amazing
app.
It
doesn't
play
music,
unfortunately,
but
we
can
enter
our
name,
click
say
hello
and
it
prints
out
our
name.
Alright.
So
that's
that's
very
basic
functionality.
But
how
would
you
test
that
the
usual
way
to
test
this
kind
of
thing
is
like
spin
up
selenium-webdriver?
Let's
get
this
thing
going,
go
find
a
button,
no
wait.
The
button
hasn't
rendered
yet
wait.
Two
seconds
then
look
for
the
button.
That's
not
really
a
good
way
of
writing
unit
tests.
A
A
A
Don't
know
why
it
does
that,
but
anyway,
it's
pretty
much
this
line
over
here
that
we
need
to
configure,
but
it
also
gives
us
a
function
called
mount
I'm,
passing
through
the
components
and
then
I'm
just
saying
dot,
HTML
I'm
going
to
log
that
out
quickly,
just
that
you
can
see
what
that
looks
like,
but
it's
essentially
going
to
log
out
the
HTML
of
our
component
as
if
it
was
rendered
to
the
Dom.
So
this
isn't
virtual
Dom
stuff.
This
is
when
it
actually
hits
the
browser.
This
is
the
HTML
that
we're
going
to
see.
A
Cool
you
can
see
over
here
doesn't
look
great,
but
there's
our
HTML
that
gets
rendered
out
instead
of
just
rendering
logging
that
out.
What
we
can
use
is
a
feature
of
just
called
snapshot
testing
and
essentially,
what
snapshot
testing
does?
Let
me
start
it
so
long
because
it
might
take
a
while
here's
it's
going
to
capture
a
snapshot
of
our
components
as
they
are
now
it's
going
to
take
a
snapshot
of
that
same
HTML
that
I
logged
out,
and
it's
going
to
save
that
in
a
file
for
us
so
the
first
time
we
run
it.
A
It's
actually
not
testing
anything.
It's
just
creating
that
initial
file
to
run.
You
can
see.
It's
created
a
folder
called
snapshots
over
here,
and
this
file
has
just
got
the
name
of
our
test,
along
with
the
HTML
that
that
rendered,
when
we
run
this
the
second
time,
it's
not
going
to
compare
that
HTML
to
the
one
that
we've
got
saved
on
disk.
So
this
is
really
good
for
picking
up
regressions
when
somebody
changes,
something
that
affects
your
components,
including
styles.
A
We
can
now
kind
of
pick
up
when
we,
when
we
get
regressions
that
start
interfering
with
our
components.
Now.
Obviously
you
don't
really
want
to
do
snapshot
testing
on
components
that
change
quite
frequently,
because
it
means
that
every
single
time
you
run
the
test
something's
going
to
be
different
and
you're
going
to
have
to
go
and
update
your
snapshots
alright.
So
if
we
change
this
to
say
hi,
instead
of
say
hello
or
in
the
test
from
here,
it
should
fail
because
of
no
longer
matches
the
snapshot.
A
A
You
for
update
snapshots-
or
you
may
have
noticed
that
webstorm
has
given
us
a
nice
little
link
which
will
just
run
that
command
for
us
and
that
will
update
the
snapshots
for
us
and
we'll
have
to
commit
those
changes
into
our
source
control.
So
I've
heard
some
horror
stories
about
the
snapshot
testing,
not
working
so
well,
specifically
giving
different
results
depending
on
the
operating
system
that
it
runs
on.
A
A
A
A
A
Cool,
so
what
we've
done
is
we've
essentially
done
almost
like
a
selenium
type
test,
but
on
a
single
component,
just
testing
the
small
part
of
functionality
of
it.
There's
no
asynchronous
stuff.
Here,
that's
gonna
break.
If
it
doesn't
find
the
button
or
you
know
the
button
hasn't
rendered,
yet
we
don't
have
to
do
any
kind
of
waiting
or
timeouts
to
make
sure
it
works.
This
is
all
synchronous
and
it's
pretty
much
guaranteed
to
always
work
or
always
fail.
A
A
It
actually
looks
exactly
like
a
previous
example
and
it
does
the
same
stuff.
It's
just
done
in
jQuery,
instead
of
react
cool
at
the
bottom
of
this
we're
importing
jQuery
and
we're
also
importing
a
say,
hello,
Jas
which
looks
like
this
now.
This
is
like
less
than
a
quarter
of
the
size
of
the
reacting
so
I,
don't
know
why
we
use
react
when
we
can
just
write
code
like
that.
A
A
So
we
don't
have
something
like
enzyme,
because
nobody
writes
stuff
like
that
for
for
jQuery
yeah,
pretty
much
that's
what
most
people's
responses
is.
Why
are
we
even
bothering
just
get
rid
of
the
jQuery?
So
there's
some
cases
where
you
can't
get
rid
of
jQuery
I
speak
from
experience.
I
have
at
least
one
jQuery
plug-in
in
production
which
I'm
not
proud
of,
but
no
one
else
makes
anything
remotely
similar
to
that.
A
Okay,
so
the
secret
the
secret
to
testing
something
like
this
is
built
into
gist.
What
it
actually
does
is
it
uses
something
called
jeaious
Dom,
it's
anyone
familiar
with
that.
It
probably
took
at
least
10
of
the
seconds
when
we
were
busy
installing
just
in
the
beginning,
it's
quite
a
big
library,
but
that's
essentially
an
implementation
of
the
Dom
written
in
JavaScript.
The
name
kind
of
gives
it
away,
but
jeaious
Dom
allows
us
to
run
a
headless
browser
anyone
familiar
with
headless
browsers,
and
this
is
actually
built
into
every
test
that
just
runs.
A
So
if
we
put
in
something
like
that,
I
mean
that
looks
completely
absurd,
like
where,
whereas
documents
exist
inside
a
node
test,
but
it's
because
we're
running
jeaious
Dom,
there's
actually
a
document
available
to
us
and
we
can
set
the
inner
HTML
and
it's
quite
easy
for
us
to
just
set
it
to
that
index.
Dot
HTML,
but
one
caveat
is
that
by
default,
JSON
does
not
run
scripts
inside
HTML.
A
A
So
to
set
our
global
dollar
sign
for
jQuery,
we
need
to
say
global
dollar,
that's
suggesting
as
well.
You
can
say
require
jQuery
and
we're
also
going
to
need
to
require
our
JavaScript
file
and
because
we're
using
jQuery
anyway,
let's
just
use
it
in
the
test.
So
let's
find
that
button
with
ID
name,
give
it
a
value.
A
A
What
we
can
do
is
we
can
actually
use
Jo
storm
separately
and
we
can
tell
Jo
storm
to
load
up
this
file
and
we
can
pass
in
the
write
flags
to
tell
it
to
actually
go
and
execute
that
JavaScript.
For
us.
That's
pretty
much.
The
only
way,
we'd
get
it
to
kind
of
fully
load.
This
file
I
mean
it's
it's
a
headless.
Browser
right
should
be
able
to
load
HTML
and
JavaScript,
but
once
that's
loaded
into
jeaious
Dom,
we
can
pretty
much
do
all
of
these
same
things
over
here.
A
A
A
A
A
Yes,
but
I
don't
know
fully,
let
me
see
if
I
can
find
it
so
so
jest
is
actually
made
up
of
a
number
of
different
packages
and
those
packages
are
all
available
separately.
So,
for
example,
there's
there's
a
specific
package
that
just
looks
for
code
that
has
changed
and
finds
the
appropriate
tests
to
run
on
it.
A
So
if
we
have
a
look
at
the
the
source
code
of
chests
and
packages,
there's
a
load
of
different
packages
here
and
you
could
import
each
one
of
these
individually,
so
I'm
not
sure
how
many
of
them
you'd
actually
need
to
import
to
get
like
a
working
just
version,
but
there's
quite
a
lot
of
them.
That
you'd
be
able
to
use
independently
without
needing
to
get
the
full
gist
kind
of
environment,
and
probably
if
you
use
something
like
a
mocker
and
just
included
some
of
these
things,
you'd
get
halfway
there.