►
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
A
Let
me
tell
you
a
little
bit
about
myself:
I'm
a
developer
advocate
at
ibm
a
node.js
core
collaborator,
a
moca
maintainer,
so
maybe
a
subject
matter
expert
and
an
openjs
foundation
cross
project
council
voting
member
on
github.
I
am
bone
skull
and
on
twitter,
I'm
bone
skull
with
a
zero
instead
of
an
o
and
to
the
right
is
my
avatar,
which
is
like
a
smirking
orange
skull
in
a
black
circle,
and
so
before.
A
Before
I
talk
about
this
workshop,
I
need
y'all
to
install
some
stuff.
You
probably
have
most
of
this
installed,
if
not
all
of
it,
but
to
do
this
workshop
you're
going
to
need
node
version,
12
or
newer,
get
version,
two
point
something
I
don't
think
it
matters
too
much.
You're
gonna
want.
Actually
you
aren't
gonna
need
a
web
browser,
but
you
will
need
a
command
line,
terminal
app
and
you're
going
to
need
a
a
text
editor
or
an
ide
of
your
choice.
A
So,
while
I'm
you
know
talking
here,
please
download
those
things
get
them
installed.
A
So
all
right.
This
is
the
outline
of
this
workshop.
I'm
going
to
start
by
talking
about
some
of
the
conventions
that
we're
going
to
use
here
and
and
how
this
is
going
to
go
next
I'll
I'll
get
you
set
up
with
the
materials.
A
A
So
things
about
this
workshop,
so
this
is
this
is
how
how
it's
going
to
go
and
what
you
can
expect
who
this
works
up,
who
this
workshop's?
For.
So
you
may
be
wondering
if
you
should
be
here
so
yeah,
I
would
say
probably,
but
I
need
to
make
some
assumptions
about
where
where
people
are
at
and
those
assumptions
are
here,
so
you
will
need
some
javascript
fundamentals-
I'm
not
going
to
teach
javascript!
A
You
should
be
able
to
do
some
basic
stuff
on
the
command
line.
You
should
be
able
to
navigate
directories.
You
know
move
around
through
the
file
system.
You
should
be
able
to
install
packages
through
npm.
A
A
And
so
there's
much
formatting
and
stuff
in
these
slides,
and
I
I
will
post
post
the
slides
after
this
workshop
here,
unfortunately,
it
looks
like
you
may
need
to
to
type
some
things.
So
these
are
the
conventions,
so
a
keyword,
it
will
be
displayed
in
bold,
and
that
is
just
some
terminology.
That'll
do
my
best
to
define
inline
code
will
be
in
a
mono
mono
space
font
emphasis
just
means
emphasis.
It
doesn't
really
mean
too
much
other
than
what
it
means.
A
A
file
name
is
displayed
in
a
monospace,
but
in
black
the
name
of
a
module,
so
a
module
on
npm,
a
built-in
module
is
going
to
be
in
italics,
a
command
that
you
are
expected
to
run
in
a
terminal
or
your
shell
is
in
green
in
a
monospace
font
link.
Is
this
kind
of
light,
blue
and
underlined?
A
And
importantly
so
this
this
one
in
red?
It
would
be
being
red,
bold
text,
these
are
instructions
for
you,
and
so
these
instructions
will
say
this
is
okay.
This
is
what
you
need
to
do
to
move
forward
in
the
in
the
workshops,
so
they're
going
to
be
little
exercises
and
everything
that
you
need
to
do
is
in
red
source
code
will
be
on
the
screen
and
it
will
be
in
like
this
blue
box
and
it
will
be
syntax
highlighted.
A
A
So
I
want
to
talk
about
what
what
testing
is
so
testing.
Software
testing
is
a
very
broad
field.
There
are
many
many
many
many
ways
to
test
software.
A
There
are
many
reasons
to
do
one
over
the
other
of
types
of
testing,
and
so
what
does
it
do
it?
So
software
testing
tells
us
about
the
quality
of
software
for
some
definition
of
quality,
and
so
that's
kind
of
that's
kind
of
up
to
you
and
your
team
and
in
your
project,
a
test
written
by
tests
are
generally
written
by
humans,
but
a
test
executed
by
a
human
is
a
manual
test.
So
maybe
that's
sending
things
over
to
the
qa
team
and
they
poke
around
your
website
and
they
try
to
break
stuff.
A
That's
manual
test
test
executed
by
a
computer.
These
are
automated
tests
and
so
automated
tests
they
make
assertions
about
software
and
an
assertion
is,
I
suppose,
the
the
dictionary
definition
is
you
know
you,
you
are
checking
something
and
you
will
you
will
say
yes
or
no,
if
it
if
it
passes
that
assertion
and
the
way
this
is
done
is
writing
more
software.
So
you
have
your
software
and
the
automated
tests
are
more
software
to
test
that
software.
A
A
If
you
know
your
intent,
you
want
to
make
sure
that
the
code
reflects
your
intent
when
software
is
well
tested
at
the
right
level
of
the
abstraction
it
helps
you
refactor
your
software,
because
you'll
know
if
you
did
something
wrong
and
you'll
know
if
you've
broken
an
interface
or
a
contract.
A
A
When
you
are
writing
well-tested
software
you're
going
to
have
a
a
better
velocity
in
the
long
term,
as
it
will
reduce
the
time
that
you
and
your
teams
spend
fixing
bugs,
and
you
will
have
time
to
do
other
stuff
like
make
more
cool
things.
Instead
of
fix
the
broken
things.
A
But
it's
not,
you
know
all
you
know
it's
not
all
roses
right.
So
there
are
reasons
why
you
wouldn't
want
to
write
tests,
so
one
thing
can
be
and
if
you've
ever
been
in
this
position,
you
know
so
a
legacy
piece
of
software,
an
old
older
piece
of
software
that
maybe
doesn't
have
tests,
may
be
exceedingly
difficult
and
time-consuming
to
test
and
to
write
tests.
A
Adding
more
tests
does
not
mean
that
you
are
adding
more
value.
It's
not
it's
not
like
a
linear
it.
It's
they're,
diminishing
returns.
So
at
some
point,
you're
going
to
get
to
a
point
where
you
know
adding
more
tests
doesn't
really
help,
and
instead
it
just
introduces
the
third
thing
in
this
list,
which
is
maintenance.
Overhead.
A
Automated
tests
are
code,
so
they
need
to
be
maintained
like
code
right,
so
there
may
be
a
maintenance
overhead,
especially
during
refactoring,
if
your
tests
are
not
at
that
right
level
of
abstraction,
maybe
they're
too
closely
bounded
the
implementation
and
I'm
not
going
to
get
into
you
know
the
kind
of
nitty-gritty
there,
but
the
testing
it
it.
It
also
can
decrease
short-term
velocity.
Anybody
that
tells
you
that
that
you
know
writing
tests
is
free,
is
is
lying
to
you
and
trying
to
sell
something
it
there
is.
A
There
is
an
up
upfront
investment
and
it
is
a
trade-off,
and
you
know
it
it.
It
tends
to
work
pretty
well,
but
you
know
there
are
certainly
reasons
that
you
might
want
to
skimp
on
it,
especially
you
know.
If
you're,
if
you
know
you
have
a
a
startup,
that's
struggling
for
cash
or
something
like
that.
A
Maybe
it's
a
good
idea.
Maybe
it
isn't?
Maybe
you
like
it?
Maybe
you
don't,
but
that's
just
kind
of
the
way
things
are
so
this
is
why
you
shouldn't
write
tests,
but
this
workshop
is
not
about
not
writing
tests.
This
workshop
is
about
writing
tests,
so
we're
going
to
go
into
the
the
the
setup
here.
So
there
is
a
git
repository
and
I
would
like
you
to
clone
it,
and
so
this
is
the
url.
A
This
is
wrapped
a
bit,
but
the
url
is
github.com
forward.
Slash
bone
skull
forward,
slash
dead,
dash,
simple
dash
testing
dash
with
dash
mocha,
and
this
contains
example
code.
A
For
the
repo
don't
mind
the
readme,
the
readme
is
a
bit
out
of
date,
but
these
instructions
are
not,
and
you
can
use
a
any
sort
of
client
you
want
to
clone.
This
is
just
the
command
line
version.
If
you
want
to
do
that
so
once
you
have
that
cloned
you're
going
to
want
to
navigate
into
the
working
copy,
which
is
the
did
simple
testing
with
mocha
directory
you're,
going
to
want
to
run
npm
install
and
what
this
is
going
to
do.
A
Is
it's
going
to
reach
into
a
bunch
of
yes,
it's
a
monorepo,
it's
going
to
reach
into
a
bunch
of
subdirectories
and
and
run
npm
install
on
there.
It's
it's
not
really
a
huge
deal,
but
I'll
wait
a
few
minutes
and
let
you
do
that
and
I'm
gonna
kill
my
camera.
I'm
gonna
give
you
about
three
minutes.
A
Okay,
I
think
I'm
going
to
move
on.
We
kind
of
have
a
lot
to
cover
so
once
you've
run
npm
install.
Of
course
you
want
to
navigate
into
the
zero
one
setup
directory.
A
And
we're
going
to
take
a
look
in
there
and
so
in
this
directory
there
is
a
directory
called
bargs
bargs.
Maybe
that
stands
for
bone
skull
args,
I
don't
know
so
what
the
bargs
package
is
is
it's
a
library
and
the
library
is
a
command
line,
argument,
parser
and
so
by
command
line
arguments.
We
have
an
example
here
we
have
dash
dash
foo
dash
dash
bar
equals
bass.
These
are
command
line
arguments.
A
You
would
give
things
like
these
to
any
sort
of
command
line
tool,
and
so
the
bargs
package
will
accept
something
like
this
and
return.
A
nice
object
for
you
and
let's
take
a
look
at
this-
is
the
project
structure.
There's
you
should
see
a
package.json
and
src
directory
and
I
would
like
you
to
open
the
bargs
forward.
Slash
src,
forward,
slash
index.js
file
in
your
editor.
A
And
if
you
cannot,
I
will
show
the
code
here
next,
but
it's
probably
going
to
be
easier
for
you
to
just
take
a
look
at
it.
A
Okay,
so
this
is
the
source
of
bargs.
Bargs
is
a
single
function.
That
function
is
called
parse
parse
accepts
an
array
of
arguments
as
the
first
option
or
the
first
parameter,
and
it
accepts
an
optional
second
parameter,
which
is
an
options
object,
and
this
is
a
pretty
common
way
of
of
a
a
common
function
signature.
A
You
will
see
some
type
defs
here
if
you're
familiar
with
js
stock
dock
strings.
These
are
actually
like
typescript
style,
jstock
things,
and
so
you
can
look
and
see.
You
can
get
more
information
about
the
the
options
allowed
here,
and
so
what
this
does
again.
It
accepts
an
array.
It's
going
to
essentially
walk
through
the
array
and
start
parsing
arguments
out
of
it.
A
It
might
start
with
three
dashes,
but
that
is
considered
a
a
like
an
option,
style
argument
and
then
anything
that
does
not
start
with
some
dashes
is
considered
a
positional
argument
and
that
winds
up
in
a
property
which
is
the
underscore,
and
so
this
is
a
convention
that
other
user
land
libraries
like
yards
use.
It's
this
underscore
contains
positional
arguments,
and
so
you
know
that's
that's
kind
of
the
size
of
it
there's.
You
know
some
special
cases
here,
but
we'll
go
into
this
in
in
more
detail.
A
You
know
the
intent.
What
exactly
it's
supposed
to
do,
but
so
this
is.
This
is
the
example
project
we're
going
to
test,
but
but
not
right
away.
So
we're
going
to
talk
about
we're
we're
going
to
have
you
write
it
or
write
a
test
now,
but
first
we
need
to
define
some
things.
Maybe
just
one
thing,
but
it's
the
word
assertion
so
an
assertion
when
I
talk
about
an
assertion
in
javascript,
an
assertion
will
check
a
condition.
A
So
maybe
that's
something
like
a
a
you
know
if
right
and
you
give
it
your
expression,
you
want
to
test
depending
on
the
result
of
that
conditional,
the
the
assertion
can
throw
an
exception,
and
so
this
is
key,
the
the
code
here
below
if
some
declared
variable
returning
true,
if
it's
true
and
returning
false,
if
it's
false,
that's
not
an
assertion.
That's
I
don't
know
what
that
is,
but
it's
it
doesn't
throw
an
exception
and
that's
key.
A
So
we
want
to
navigate
into
this
zero.
This
this
other
lesson
directory
so
or
exercise
directory.
Whatever
it's
called.
We
want
to
go
back
up
to
the
root
of
dead,
simple
testing
with
mocha.
We
want
to
go
into
the
zero
to
your
first
test
directory.
We
want
to
go
into
the
bargas
directory
in
there.
Then
I
want
you
to
make
a
test
directory.
A
One
may
already
exist
so
if
it,
if
it
doesn't
exist,
go
ahead
and
create
that
that
might
want
to
be
in
make
dirt
p,
then
I
want
you
to
create
a
new
file
in
this
test
directory
and
call
it
bargs.spec.js.
You
can
call
it
really
whatever
you
want,
but
this
is
the
file
name.
I'm
going
to
use
here.
Dot
spec,
dot
js
is
is
just
a
convention.
You
don't
have
to
use
it
a
lot
of
people,
don't
maybe
you
want
to
call
it.test.js
it
doesn't
matter.
A
A
Done
so
say
we
have
this
empty
file.
I
want
you
to
put
this
in
it.
So
if
false
throw
new
error,
that's
it.
So
I
guess
I
guess
you
can't
very
well
copy
and
paste
this,
but
go
ahead
and
type
that
out.
I
can
again
after
this.
I
will
try
to
export
this
this,
these
slides
in
a
form
in
which
you
can
copy
and
paste,
but
for
now
please
just
type
that,
and
what
we
have
here
is
a
test.
A
So
you
know
a
test
contains
some
sort
of
assertion
and
you
know
it's
a
it's.
It's
a
static
assertion,
so
false
will
always
be
false,
but
we
have
made
an
assertion
here
now.
If
false
is
true,
what
would
happen?
We
would
throw
an
error
and,
and
the
test
would
fail,
but
this
is
a
test.
This
is.
This
is
all
it
is
so
now
we
want
to
run
this
code,
so
I'm
going
to
assume
you've
typed
something
out
like
this
and
we're
going
to
go
ahead
and
run
it.
A
So
I
would
really
expect
nothing
to
happen
at
all.
I
would
expect
the
code
to
be
executed.
I
would
expect
the
process
to
just
exit
and
that's
it
and
that's
that's
that's
what
a
passing
test
looks
like
looks
like
so
your
your
mission,
then,
is
to
make
this
test
fail.
However,
you
see
fit
so
you're
going
to
go
back
into
the
barge.spec.js
file
and
you're
going
to
change.
A
A
Okay,
so
here
here's
here's
what
I
would
do
I
would
change
the
false
to
true
and
that
would
that
would
exit
it
or
that
would
throw
the
exception
and
and
make
the
make
the
test
fail,
and
that's
that's
really
it
that
there's
there's
your
failing
test,
so
we've
got
a
passing
test
and
a
failing
test
and
it's
extremely
basic
and
you
could
write
tests
this
way
if
you
wanted
to,
but
it's
not
so
much
fun,
so
it
works.
But
it's
it's
too
much.
Boilerplate,
there's
there's!
A
You
know
you're
going
to
start
finding
that
you're
making
the
same
checks
over
and
over
you
will.
I
don't
know
if
there's
a
name
for
these,
but
I'm
going
to
call
them
assertion
patterns
and
so
you're
going
to
find
that
you're,
making
these
checks
again
and
again
so
we're
going
to
check
is
this.
Is
this
value?
True?
Is
the
value
false?
A
Does
value
x,
equal
value
y?
Does
the
function
z,
throw
under
certain
set
of
circumstances
and
if
it
does,
which
exception
so
these
are.
These
are
some
examples
of
common
assertions
that
you're
going
to
see
again
and
again,
and
so
that's
why
we
get
things
like
the
assert
module,
so
the
assert
module
is
in
node
and
you're,
probably
going
to
want
to
go
check
out
the
docs
right
there.
A
That
is
nodejs.org
forward,
slash
api
forward,
slash
assert.html,
and
this
is
the
built-in
assert
module
and
what
it
provides
is
assertion
patterns
as
functions,
and
so
we're
going
to
use
this
instead
of
what
we
just
did.
So
I
want
you
to
add
something
like
const
assert
equals
require
assert
to
the
top
of
your
barge.spec.js
file.
A
And
so
the
exercise
then
well
actually
so
the
the.
So
let
me
talk
a
little
bit
more
about
the
assert
module,
and
so
what
that
does
is
it
provides
all
these
assertion
patterns
all
the
assertion
patterns,
throw
if,
if
for
depending
on
the
reason
but
depending
on
the
function,
and
why
they
will
throw
an
insertion
error,
which
is
an
exception,
it's
just
a
special
subclass
of
error.
It's
an
assertion
error.
It
contains
some
extra
metadata
about
the
failed
assertion.
A
Yeah,
it's
it's
handy.
So
please
note
that
we
are
not
talking
about
there's
a
module,
one
npm
called
assert,
which
may
be
roughly
the
same,
but
we're
talking
about
the
built-in
assert
module
in
node,
so
you
shouldn't
have
to
go
in
npm,
install
and
assert
because
it's
already
there.
A
So
I
want
you
to
replace
your
assertion
on
this.
You
know
if
this,
where
is
it
this
here,
replace
this
with
a
call
to
a
single
function
in
the
assert
module,
and
so
there's
going
to
be
probably
more
than
one
function
you
could
use
in
there,
but
yeah
give
it
a
shot,
see
if
you
can
replicate
this
except
use
the
assert
module
to
do
so,
and
I
will
wait
a
couple
minutes.
A
Okay,
so
the
hint
is
use
the
okay
function,
so
it's
cert.okay
again
there
are
others
you
could
use,
but
I'm
gonna
go
with
that.
One
and
I'll
give
you
another.
A
A
It
will
say
okay,
so
we
expected
true,
but
what
we
were
passed
is
false
operator
must
be
the
operator
that
it
uses
to
to
make
the
comparison.
So
the
thing
about
assert
okay
is:
it
does
not
do
like
a
strict
check,
it's
a
it's.
It
uses
coercion,
it
uses
the
double
dash.
So
if
you
say
something
like
zero
equals
equals
false.
That
would
be.
That
would
be
the
kind
of
truthiness
we're
talking
about
here.
A
So
the
what
I
came
up
with
was
this.
So
we've
used
the
assert
module
here
and
again.
This
is
a
not
a
strict,
a
quality
check
and
we've
used
the
okay
function
and
we've
given
it
false,
and
it
should
fail
every
single
time.
A
You
run
it
so
now
we
can
change
this
test,
we'll
fix
it
and
so
it
passes,
and
this
should
be
pretty
trivial,
but
when
it
passes
what
you
should
expect
is
that
nothing
happens
and
that's
again,
that's
often
what
often,
what
passing
things
will
look
like,
but
I'll
wait
just
a
minute.
A
Okay,
so
any
one
of
these
things
would
work
because
of
the
it's
okay.
Does
it
doesn't
check
the
strict
true
value,
it's
a
truthiness
check,
and
so
you
could
use
any
of
these,
and
this
is
trivial,
but
it
it
it.
It
illustrates
the
point
so
this
file,
this
barge.spec
js,
it's
a
test,
we're
testing-
I
don't
know
the
booleans.
I
suppose,
but
it's
this.
These
are
really
all
tests
are
they're,
just
assertions.
A
Anything
else
is
kind
of
decorations
around
that
and
you'll
you'll
have
noticed
that
we
haven't
touched
bargs,
so
we're
going
to
look
at
at
bargs
here
in
the
next
section
and
believe
it
or
not
we're
not
even
going
to
use
mocha
yet,
but
so
yeah.
Here
we
are.
This
is
what
we've
learned
so
far.
A
We've
learned
about
assertions
in
javascript
we've
learned
how
to
run
a
very
basic
test
file
and
we've
learned
about
the
assert
module
built
into
node
and
now
we're
going
to
write
some
more
real
looking
tests
and
so
barge.
Let
me
talk
a
little
bit
more
about
bargs,
so
this
is
like
the
the
motivation
for
barks.
So
the
command
line,
arguments
in
a
node
app
are
provided
as
an
array
but
parsing.
A
There
are
lots
of
packages
out
there
that
do
this
lots
of
them
yargs,
commander
minimist,
and
they
do
it
much
better
than
bargs.
Does
okay,
so
they're
they're
good
packages.
A
Bargs
is
intended
to
just
be
like
the
minimum
set
of
things
that
you
would
possibly
want
for
for
this
sort
of
functionality,
and
again
it
has
a
single
exported
function
which
is
parse
so,
and
this
I'm
going
to
show
you
a
table
next
of
examples,
so
we're
going
to
have.
This
is
what
we
give
bargs
the
parse
function.
This
is
what
we
pass
to
it,
and
this
is
what
we
expect
back,
and
so
this
will
kind
of
cover
the
use
cases
that
we're
talking
about
and
command
line
argument.
A
Parsing
is
there's
a
lot
going
on
there,
but
again,
I'm
trying
to
distill
this
down
to
the
to
the
the
very
minimum
that
we
need
so.
A
Here
we
have
a
table
and
the
first.
A
The
first
column
here
is
the
input
array,
so
this
is
what
we
would
pass
the
the
parse
function
and
the
second
column.
The
output
is
what
we'd
expect
back,
and
so
we
have
these
different
situations
that
we
need
to
handle.
A
You'll
notice
that
there
are
notes
on
some
of
these,
because
it
needs
a
little
bit
of
a
direction
to
do
certain
things,
so
you
will
probably
want
to
come.
Maybe
I
should
just
come
back
to
it,
but
this
is
this
is
something
you're
gonna
want
to
look
at
again.
I
note
that
the
that
the
output
object
will
always
have
an
underscore
property,
and
if
there
are
no
positional
arguments,
it'll
be
an
empty
array.
So
you
don't.
A
You
don't
need
to
worry
too
too
much
about
this
right
now,
but
this
is
just
showing
okay.
This
is
this
is
the
intent.
This
is
what
we
expect
to
happen.
We
you
know
we
exp.
We
expect
a
a
an
option
that
does
not
have
any
sort
of
parameter
after
it.
That's
supposed
to
be
a
boolean,
so
there's
a
boolean
flag.
Yes,
no,
we
expect
that
stuff
that
only
has
one
dash
is
is
also
a
boolean
if
it
does
not
have
any
sort
of
parameter.
A
If
we
use
an
equals
sign,
that
means
we
have
some
sort
of
parameter.
If
we
don't
use
an
equal
sign
here
on
line
one
two,
three
four,
five,
six
we're
gonna
need.
Some
you
know,
bargs
is
gonna
need
direction
to
figure
out.
Okay.
A
What
is
baz
here
is
baz
this
the
parameter
to
foo,
or
is
that
a
a
positional
argument
it
needs?
It
needs
a
hint
if
we,
you
know,
do
give
it
something
that
doesn't
have
any
dashes.
That's
just
the
positional
and
we
can
see
that
on
the
next
line,
but
so
these
are
just
again
examples.
Another
special
case
is
this
bare
double
dash,
and
so,
if
you've
seen
that
before,
maybe
in
command
line
command
line
scripts,
everything
after
that
double
dash
is
supposed
to
be
a
positional
argument.
A
It's
supposed
to
be
kind
of
red,
as
is,
and
so
that's
how
we're
going
to
treat
this
if
we
pass
something
with
starting
with
dashes
after
that
double
dash,
that's
still
considered
a
positional,
and
so
it
seems
like
a
lot,
but
it's
like
it
really
is
kind
of
the
bare
minimum
of
what
you
need
to
do.
A
Another
thing
is
that
by
default,
bargz
works
on
process,
dot,
rv.slice2
and
so
process.rb
dot.
Slice
2
is
essentially
your
your
command
line
options.
The
the
first
and
second
element
of
that
process.org,
the
array
you
don't
usually
need
it's
like
the
node
executable
and
the
script
name,
you
just
care
about
the
stuff
after
it,
and
so
it
uses
that
by
default.
A
But
you
can
give
it
a
an
explicit
array,
so
we
want
to
pull
bargs
into
our
test
file,
and
so
I
want
to
make
sure,
let's
see
here,
we
should
be
actually
in
the.
A
I
believe,
whichever
sorry
I
didn't
add
this
one,
but
it's
whichever
directory,
where
it
says
actual
tests
and
so
in
the
dead,
simple
testing
with
mocha
there's
going
to
be.
You
know
several
directories
with
numbers.
You
want
the
one
that
says,
I
think
it
says:
zero
three
actual
tests,
you
want
to
go
in
there
and
we
want
to.
A
A
So
what
we're
going
to
do
with
bargs
is
we're
going
to
write
a
unit
test
for
it,
and
a
unit
test
is
a
test
that
makes
again
an
assertion
like
in
the
other
test,
and
it's
going
to
make
an
assertion
about
a
unit,
but
now
we
have
to
define
unit
what's
a
unit
a
unit
is
the
smallest
testable
bit
of
code
right.
So
what
is
generally
the
smallest
testable
bit
of
code
generally,
that
is
a
function
and
for
our
purposes
it's
a
function.
A
A
So
what
we
want
to
do
with
a
unit
test
is
we
want
to
try
to
test
that
function
independently
of
other
functions,
that's
kind
of
a
a
broad
topic
as
well
how
to
achieve
this
independence
or
isolation
when
testing
a
function,
but
I'm
not
going
to
go
into
it
here.
So
we
have
a
single
function,
parse
and
that's
what
we're
going
to
test.
But
where
do
we
start
testing?
A
You
know
what
you
what
you
prefer
to
do
I
like
to
start
testing
exceptions,
so
here
there's
going
to
be
this
line
highlighted
in
orange,
okay,
and
so
this
expects
value
property.
A
This
is
how
we
tell
barge
that
a
an
option
say
dash
dash
foo
expects
some
sort
of
parameter
after
it.
So
maybe
we
want
to
say
dash
dash,
require
hypothetically
dash
dash
require
baz
right,
so
we
have
a
command
and
we
want
to.
We
want
to
pass,
require
baz
to
it,
and
we
don't
want
to
have
that
equal
sign
in
there
and
the
only
way
to
do
that
is
to
give
bargs
a
hint
that
hey
we.
A
We
are
expecting
a
value
for
this
require
option,
and
so
in
that
ops
we
would
have
this
expect
value
array
and
in
that
array
we
would
have
require,
and
that
tells
bargs
hey
require,
expect
something
after
it.
A
And
so
you
know
this,
this
is
javascript
and
it's
kind
of
loosey-goosey,
so
we're
doing
a
basic
check
to
see
if
argv
is
an
array.
If
it
is
not
an
array,
we
assume
that
we've
passed
it
an
options
object,
and
we
assume
that
we
just
want
to
use
the
default
here.
Actually
I
think
that
might
not
even
be
necessary,
I
think
that's
redundant,
but
so
yeah
we
want
to
actually
no
it's
not
it's
fine.
A
So
we
want
to
allow
a
user
to
pass
just
an
option,
options,
object
and
we'll
use
the
default
process,
rv
slice
too.
A
A
We're
making
a
new
set
from
ops
expects
value,
but
this
function
is
written
so
that,
if
you
do
not
pass
opts,
you
will
get
a
expects
value
of
an
empty
array.
But
if
you
do
pass
it
and
you
give
it
an
expects
value
and
you
give
it
something-
truthy
that
isn't
an
array
parse
will
throw
an
exception
because
you
cannot
or
something
that's
not
iterable.
Anyway,
you
cannot
just
instantiate
a
new
set
with
like
a
number
or
something
it
has
to
be
something
that
is
iterable.
A
So
what
we're
gonna
do
is
make
a
a
expects.
A
Let's
see
we're
gonna
make
an
assertion
that
checks
are
parse
function
for
this
behavior,
and
so
let's
go
in
here,
so
we
want
to
check
an
exception,
but
before
we
do
that,
why
we
want
to
do
that
because
bugs
is
a
library
you're
going
to
have
people
using
the
library.
Maybe
and
parse
is
a
public
api.
It's
the
interface
of
the
function,
and
so
when
people
use
your
library,
they
expect
it
to
work
and
they
expect
it
to
fail
in
the
same
way.
A
So
you
might
not
think
about
it,
but
it's
like
yeah,
that's
that's
another
one
of
the
the
it
might
not
be
in
the
explicit
api,
but
people
will
expect
your
code
to
fail
how
it
has
always
failed,
and
if
we
don't
check
our
failure
states,
we
could
break
that
and
break
users
and
and
cause
problems
with
consumers.
So,
let's
see
here,
we
want
to
I'd
like
to
check
if
we
are
where
we,
where
I
think
we
are
here.
So
let
me
pop
out
of
here
really
quick
and.
A
Too,
all
right
yeah,
so
I
had
left.
I
had
left
out
directions
here,
but
what
we
want
to
do
is
come
on.
A
We
want
to
go
into
the
zero
three
actual
test
directory
and
that
directory
is
again
a
barge
directory.
There
is
a
test
directory
and
there
is
a
bargas.spec.js
file
in
there
already
and
that
file
contains
it
contains
this
okay,
and
so
we
want
to
change
this,
and
the
first
thing
we
want
to
do
to
it
is
we
want
to
require
this
parse
function.
A
So
at
the
top
of
this
file,
which
is
in
the
zero
three
actual
tests
forward,
such
bars
forward,
slash
test,
we
want
to
add
something
like
const
parses
require
and
so
it'll
it'll
go
and
it'll
grab
the
function
out
of
barks.
There
are
other
ways
to
do
this,
but
that's
how
we're
doing
it
here.
A
So
what
we
want
to
do
is
we
have
all
these
assertions.
You
can
delete
them
all,
and
so
you're
gonna
have
your
test
file,
it
will
have
require
assert
and
it
will
have
a
require
of
bargs,
and
so
what
we
want
to
do
is
replace
all
this
all
this
stuff.
With
a
call
to
assert.throws
and
again
you're
going
to
want
to
look
at
these
docs
and
again,
it's
the
assert
module
nodejs.org
forward,
slash
api
cert.html
you're
going
to
want
to
look
at
assert.throws,
and
that
is
a
function
in
there.
A
That's
api
in
the
cert
module
and
what
that
function
is
going
to
do.
It
accepts
a
function.
It
accepts
a
function,
it
does
not
accept
a
return
value
except
a
function
to
be
clear
about
that,
and
so
we're
going
to
pass
it
a
function
and
we
want
to
pass
it
a
function
which
calls
parse
and
we
want
to
call
parse
with
an
ops
parameter
of
expects
value,
and
we
want
to
give
it
a
like
a
empty
object
for
the
value
of
expects
value.
A
Okay,
and
so
what
we
want
to
do
is
we
want
to
make
sure
what
we're
trying
to
do.
We
want
to
make
sure
when
we
pass
expects
value
with
an
empty
object.
We
want
to
make
sure
our
tests
are.
Our
tests
are
excuse
me.
Our
parse
function
throws
an
exception,
so
the
test
should
pass,
but
bargs
should
throw
an
exception,
and
so
I
will
wait
a
minute
while
you
check
this.
A
A
Okay,
so
again,
if
you've
done
this
correctly,
what
should
happen
when
you
run?
It
is
nothing
should
happen,
and
that
is
your
that's
your
passing
test.
If
you
did
something
wrong,
you're,
probably
gonna
get
an
exception,
but
this
is
what
I
came
up
with.
A
So
your
barge.spec.js
should
look
like
this
now,
so
we're
calling
the
throws
function
in
the
assert
module
and
we're
giving
it
a.
A
A
This
is
what
we're
testing
this
this
this
little
arrow
function,
and
so,
when
we
do
that,
we
also
give
the
assert
throwstep
function,
some
some
information
about
the
assertion
that
we
expect
back,
and
so
what
I
would
expect
out
of
this
is
a
type
error
and
that
will
throw
out
of
the
call
to
new
set
again
so
we're
calling
new
set
and
we're
giving
it
something.
That's
not
iterable
we're
going
to
get
something
like
object,
is
not
iterable
that'll,
be
the
message
and
that
error
will
be
a
type
error.
A
So
what
would
happen
if
we
modified
this,
and
I
would
actually,
I
would
suggest
you
copy
what
I
have
here.
But
what
happens
if
we
modify
the
name
to
read
error
instead
of
type
error?
What
would
happen?
You
think
it
would
fail?
A
We
are
using
a
regular
expression
here
to
test
the
message
and
the
message
is
going
to
be
longer
than
object
is
not
iterable.
I
don't
know
exactly
what
it
says,
but
some
portion
of
that
message
this
this
regular
expression,
says
some
portion
of
the.
The
message
should
look
like
this,
but
it
doesn't
need
to
match
the
message
exactly
and
so
that's
kind
of
handy,
especially
yeah
messages
and
exceptions
can
change.
A
It
would
be
cool
to
sorry
all
the
a
bunch
of
errors
thrown
out
of
node
now
have
this
code
property,
which
is
a
better
thing
to
check
here.
We
don't
have
that.
A
A
We
want
to
add
another
assertion
now,
and
so
I
think
we
should
probably
do
is
so
assuming
your
bard
spec
just
looks
like
this
copy
the
assertion
and
paste
it
again
and
then
change
the
value
to
one
instead
of
a
empty
object
and
we're
going
to
use
just
we're
going
to
write
just
another
assertion
to
do
this
and
when
you
run
it,
it
should
fail
and
I'm
going
to
need
you
to
go
in
and
change
the
the
options
to
assert.throws
so
that
the
test
passes.
A
A
Updated
it,
so
it
would
look
very
similar
to
the
last
one
that
we
wrote,
except
the
message
will
say:
number
one
is
not
iterable,
it's
not
going
to
say.
Object
is
not
integral
number
one
is
not
iterable
and
so
yeah,
so
these
are
how
to
test
exceptions
coming
out
of
our
our
function
and
and
and
the
cool
thing
about
writing
tests.
This
way
is,
it
makes
you
think,
a
bit
more
about
about
the
api,
the
function
api
that
you're
writing.
A
A
And
if
it
isn't,
then
I'm
going
to
throw
a
custom
error
that
says
something
like
expects
value
should
be,
you
know
an
array,
and
that
would
just
be
kind
of
more.
I
think
consumer
friendly,
but
just
something
to
note
that
you
know
writing
tests
like
this
can
help
you
really
kind
of
dog
food
kind
of
feel
how
how
it
it
feels
to
use
an
api
that
you're
writing,
and
so
we've
done
our
exceptions,
and
I
want
to
move
on
to
actually
checking
the
what
happens
when
parse
does
not
throw
right.
A
So
this
is
the
the
usual
usage
of
of
parse
we're
going
to
give
parse
valid
input,
so
an
array
of
command
line
options
and
then
we're
going
to
check
the
return
value
and
if
you
go
into
you
probably
still
have
the
the
documents
open
if
you've
looked
at
them
at
all.
But
if
you
have
the
documentation
open
for
the
assert
module
you
can
poke
around
in
there
and
you'll
see
that
there's
a
does
not
throw
function.
A
You
don't
want
that
for
this,
so
it's
it's!
It's
for
like
void,
functions
right.
So
if
you
have
a
function
that
has
side
effects,
for
example-
maybe
you
just
want
to
check
that
it
that
it
doesn't
throw
because
it's
not
going
to
ever
return
anything
right,
but
in
our
case
our
function
returns
something
it
should
return
the
same.
You
know
it
should
yeah.
We
want
to
just
test
the
return
value
because
we
can.
A
So
what
we
want
to
do
is
add
a
third
assertion,
so
your
barge.spec.js
should
have
these
first
two
assertions
about
the
exceptions.
It
should
have
a
third
exertion
assertion
now
now
you
want
to
pass
this
array
right
here.
A
A
Yeah,
that's
that's
misdirection
a
bit.
So
what
I
would
do
is
this:
instead
I
would
go
and
we
would
we
would
check.
We
would
pass
this
parse
to
assert.deepstrict
equal
and
we
want
to
expect
just
give
it
like
an
empty
object
right.
A
So
that
would
be
the
second
parameter
and
so
you're
going
to
run
that
code
and
it's
going
to
fail
and
you're
going
to
it's
going
to
tell
you
why
it's
say:
oh
well,
it
doesn't
match
this
empty
object
is
not
what
parse
returned.
It
returns
something
else
entirely
and
so
you're
going
to
want
to
look
at
that
and
see
what
it
what
it
returned
and
update
your
assert
accord,
assert
call
accordingly
and
so
I'll
give
you
a
minute
to
look
into
that.
A
But
another
thing
is:
do
not
use
deep,
equal
or
equal.
Those
those
functions
are
both
deprecated.
You
want
deep,
strict,
equal
or
or
strict
equal,
and
here
especially
you
want
deep,
strict
equal.
This
is
deep.
Strict
equal
is
for
comparing
objects.
Strict
equal
is
for
comparing
primitive.
So
that's
why
you
want
to
use
this
function,
so
I'm
going
to
wait
a
minute
and
we're
going
to
check
that
return,
value.
A
Okay,
so
this
is
what
I
came
up
with
for
for
this
one,
so
we're
going
to
call
assert
deep,
strict,
equal
and
we're
going
to
pass
it
we're
passing
it
the
return
value
of
parse,
we're
not
passing
it
a
function,
we're
passing
we're
actually
making
a
call
to
parse
and
we're
giving
it
the
arrays
array
we
expected
and
we're
going
to
get
back
underscore
empty
array,
which
again
is
these
positional
arguments
and
we're
going
to
get
foo.
A
But
in
our
case
this
is.
This
is
probably
the
correct
thing
to
test
so
great
we've
written
some
tests
in
a
file,
it's
just
a
bunch
of
assertions,
and
so
there's
this
is
yeah.
This
is
not
good.
There
are.
There
are
problems
with
with
doing
it.
This
way.
A
They're,
not
you
know
you
can
overcome
them.
You
know
node
node.js
itself,
tests
itself,
essentially
in
this
manner.
But
what
happens
if
you
run
this
file-
and
it's
got
these
three
assertions
in
it
and
the
second
assertion
fails.
A
Okay,
so
if
we
want
to
make
sure
that
all
of
our
stuff
gets
executed,
we
would
maybe
wrap
things
and
try
catch,
but
that's
adding
boilerplate
right,
so
yeah,
you're
gonna,
maybe
write
a
function
to
do
that.
For
you
then
you've
started
writing
a
test
framework,
but
there
are
kind
of
limited
options
for
organization
here.
Maybe
you
can
come
up
with
your
own
set
of
functions
to
help
organize
things
otherwise
you're
you're
kind
of
stuck
adding
you
know
using
like
a
bunch
of
different
files.
B
A
There's
limited
options
for
organ
organizing
your
code.
Unless
you
essentially
again
write
some
sort
of
framework,
you
can
only
run
a
single
file
at
once.
Maybe
you
have
written
a
script
to
include
all
of
your
other
test
files,
but
that
seems
like
a
pain
in
the
butt
or
you
know
it's
going
to
need
a
custom
script.
A
If
you
want
to
run
more
than
one
file
at
once,
because
you
can't
just
give
a
whole
bunch
of
files
to
node,
you
give
node
one
script
and
that's
what
it
runs
and
so
limited
reporting
options
right,
so
we're
throwing
if
something
fails,
but
what
happens
on
success
again,
you're,
not
seeing
anything.
If
all
our
assertions
pass,
the
the
process
will
just
exit
with
exit
code
0
and
it
won't
print
anything.
A
And
so,
if
you
want
more
information
than
that,
you're
gonna
have
to
code
it
up
yourself
and
again,
that's
like
going
down
the
path
of
the
right,
a
test
framework,
and
so
this
is
where
test
frameworks
that
have
already
been
written
can
help
you,
and
this
is
where
milka
can
help
you.
So,
let's
talk
about
what
we've
done
in
this
actual
testing
section,
so
we've
talked
about
bargs,
which
is
a
library
for
parsing
command
line
arguments.
A
A
We've
learned
how
to
test
a
module,
so
we
have
a
test
file,
we've
pulled
in
our
module
bargs
and
we've
run
some
tests
against
it.
We've
learned
how
to
use
the
assert
module
built
into
node
to
test
exceptions,
the
behavior
of
our
parse
function
and
how
it
throws
some
exceptions.
We've
learned
how
to
assert
the
return
values
for
a
given
input
from
from
parse,
and
we've
learned
how
this
can
kind
of
snowball
a
bit
and-
and
this
is
how
something
like
mocha
could
help.
A
It's
a
framework
right.
So,
if
you
think
of
a
framework-
maybe
you
think
of
I
don't
know,
react
angular
express
stuff
like
that
and,
like
other
frameworks,
mocha,
the
the
aim
here
is
to
allow
you
the
developer,
to
focus
on
your
specific
application,
application
specific
details
instead
of
calling
into
the
library
and
and
making
functions
that
way.
A
Like
other
frameworks,
you
kind
of
fill
in
the
blanks
with
your
your
application.
Specific
code,
like
you,
would
write
a
react
component
react
provides
this
framework
for
four
components,
and
maybe
you
write
write
a
component.
You
kind
of
fill
in
the
blank
with
with
what's
unique
to
your
code
and
mocha
works.
The
same
way.
It
says.
Okay,
you
fill
in
the
blanks
with
your
tests
and
assertions,
and
I'm
going
to
give
you
some
some
functions
to
help.
A
You
do
that
so
and
mocha
again,
mocha's
purpose,
much
like
the
purpose
of
any
framework
is
to
make
make,
make
it
easier
to
do
what
you're
trying
to
do
and
and
focus
on
the
the
specific
concerns
that
you
have.
Instead
of
needing
to
worry
about
these
things
that
you
always
need
to
do
like
you
always
need
to,
you
know
maybe
report
on
on
failures,
you
always
always
need
to
report
successes.
Maybe
you
don't
always
need
to,
but
you
always
need
to.
You
know,
have
some
some
some
way
to
organize
things.
A
You
know
you
always
need
to
be
able
to
run
multiple
files
at
once,
so
you
know
mocha
a
framework,
a
test
framework.
Its
purpose
is
to
to
make
this
easier.
So
now
we're
going
to
go
into
this
zero,
four
introducing
mocha
directory,
and
so
that's
right
off
the
working
cup.
A
The
main
root
in
the
dead,
simple
testing
with
mocha,
want
to
go
into
the
zero
four
directory
and
in
there
there's
another
bargs
and
in
this
one-
and
I
hope
I
haven't
done
this
already-
but
we
want
to
install
mocha
in
here,
okay,
so
you're
going
to
go
into
this
directory
and
you're
going
to
install
mocha
as
a
dev
dependency.
A
Typically,
if
you're
going
to
use
mocha
on
an
actual
project,
you're
going
to
want
to
install
it
as
a
dev
dependency,
the
only
way
time
you
would
not
want
to
do.
That
is
generally,
if
you're
trying
to
build
a
plug-in
or
something,
and
even
then
yeah.
If
you're
trying
to
build
on
top
of
mocha,
you
might
not
want
to
use
a
dev
dependency,
but
generally
just
do
that.
So
I'll
wait
a
sec.
A
While
you
go
into
o4,
introducing
mocha
and
install
npm
install
in
bargs
and
again,
there
should
be
a
package
json
in
there
and
it
should
update
your
package
json
when
you
do
that
it
might
even
make
a
lock
file.
I
don't
know
but
yeah,
please
install
mocha
and
I'll
give
this
a.
A
A
All
right
it
shouldn't
take
that
long.
I
mean
it's
not
that
bad.
So,
let's
assume
we
have
milk
installed
in
this
zero,
four
introducing
mocha
bargs,
so
yeah
we
got
it
in
there
and
now
we
can
open
up
our
package.json
and
in
that
package.json
there
should
be.
A
There
should
not
be
a
scripts
property,
but
we
want
to
add
one.
So
we
want
to
add
a
script
called
test
and
what
the
value
of
that
script
should
be
is
mocha
test
for
slashbox.spec.js.
A
And
so
what
this
is
going
to
do
is
this
is
going
to
allow
us
to
run
our
tests
with
npm
just
by
typing
npm,
test
on
the
command
line,
and
so
once
you've
added
this
to
pack.json,
and
you
may
need
a
comma,
don't
forget
your
comma
somewhere,
but
once
you've
added
it
exit
and
run
npm
test.
And
what
you
should
see
is
something
like
zero
passing.
A
And
the
reason
you
will
see
zero
passing
is
so:
oh
yeah
that
test
barge.spec
that
has
been
that
should
be
updated
to
include
all
the
assertions
we
wrote
in
the
last
section,
so
yeah,
so
that
does
have
the
assertions
in
it.
A
But
when
you
run
npm
tests
you
should
see
zero
passing,
and
that
is
because,
while
the
code
in
vargs.spec
js
is
being
run,
it
is
not
running
in
a
way
that
mocha
knows
about,
and
so
it's
a
framework
and
there
are
conventions
and
api
calls
and
things
and
we're
not
using
any
of
those.
Yet
so
you
should
see
zero
passing
when
you're
on
npm
test.
A
A
A
Mocha's
default
api,
it
it
sort
of
mimics
natural
language,
and
it
you
if
you're
coming
from,
I
don't
know
java
or
something-
and
you
see
this-
this
api
you're
gonna
be
like
what
so
it's
it's.
The
name
of
the
function
to
create
a
test
by
default.
Mocha
is
it,
I
t
it
and
that's
a
global
api.
So
when
you
write
a
test
in
mocha,
you
don't
need
to
require
mocha
or
import
mocha.
A
A
I
think
it's
about
eight
or
nine
years
old
now
and
it
was
inspired
by
a
testing
package
for
ruby
and
that
testing
package
is
r-spec,
and
so
our
specs
api
looks
a
lot
like
mocha's
api
and
so
for
whatever
reason-
and
I
don't
really
know,
I
don't
really
understand
the
spread
of
things.
But
now
you
know
in
mocha
we
have
this
kind
of
natural
language.
A
A
If
you're
really
interested,
you
can
look
it
up,
but
it
doesn't
really
matter
because
we're
just
talking
about
the
api
and
it
does
yeah
it's
it's,
I'm
not
going
to
go
into
bdd,
but
you
don't
really
need
to
know
anything
about
bdd
to
use
mocha
or
any
of
these
testing
tools.
You
just
need
to
understand.
Oh
okay,
this
is
what
the
api
looks
like
and
and
that's
what
it
means.
So
that's
what
a
test
is
in
mocha.
A
What
we
want
to
do
is
we
want
to
open
our
bargs.spec.js,
which
again
should
have
all
these
assertions
already
in
it.
It
should
have
three
assertions
and
we
want
to
emocify
this
test
file
and
so
how
we're
gonna
do.
That
is
oh
monitor.
A
I'm
not
sure
if
we
just
lost
that
monitor
it's
got
a
flaky
power
cord,
I
don't
know,
maybe
we're
still
it's
still
up.
If
it's
still,
if
it's
not
up,
please
somebody
tell
me
anyway.
A
So,
let's
see
here,
okay,
great
so
right,
we
want
to
wrap
the
call
to
assert
module
in
a
test,
and
so
it's
going
to
look
like
this,
so
that
very
first
assertion
we
made
about
the
type
error
where
we
pass
it
a
bear,
object,
we're
gonna,
we're
gonna,
do
something
like
this,
and
I
want
you
to
type
this
out.
A
So
it
should
throw
a
type
error,
and
this
is
the
title:
should
throw
a
type
error
and
the
body
is
this
function,
and
so
in
that
function
we
need
to
put
an
assertion.
A
Okay,
so
you
don't
need
to
remember
you
don't
need
to
require
mocha
or
anything
you
just
you
just
write
it
it's
there
when
you
run
this
with
mocha
okay,
so
for
each
of
these
three
calls
to
assert
we're
going
to
wrap
it
in
in
a
in
a
mocha
test
and
we're
going
to
give
each
a
title.
A
And
again
the
title
describes
the
behavior
we're
testing
okay,
so
the
first
two
would
say
something
like
throw
a
type
error
and
the
last
one
should
be
like
it
returns
some
sort
of
object,
but
yeah.
We
want
to
wrap
those
assertions
in
a
call
to
it
and
we
want
to
put
that
assertion
in
the
second
parameter,
which
is
the
the
test
body
and
I'll
wait
just
a
second
for
you
to
to
wrap
this.
A
A
Oh
okay,
so
if
you
did
this
right,
what
you're
going
to
see
when
you
run
npm
test
is
something
like
this.
A
A
If
you
didn't
get
this
working,
maybe
you'll
see
something
like
this
and
I
apologize
for
the
two
columns
here,
but
so
maybe
the
third
one
didn't
work
for
whatever
reason,
you're
gonna
see
something
like
this.
So
we'll
see
the
should
throw
a
type
error.
Those
two
have
passed
and
we'll
see
this.
The
the
third
test
is
failing,
and
this
is
what
the
output
for
mocha
looks
like.
If
your
tests
are
failing.
B
A
But
anyway
we
don't
we
don't
want
to.
We
don't
want
to
do
that.
We
want
our
tests
to
pass.
So
this
is
what
this
is.
What
I
came
up
with
for
this
and
that's
how
I
got
the
success.
This
is
how
I
got
this
here.
It's
so
we
have
three
tests.
It
should
throw
a
type
error
and
then
there's
this
function,
which
is
the
body
and
in
that
body,
is
just
the
assertion
we
wrote
before.
A
Okay
and
the
second
one
is
similar
again,
the
the
title
of
a
test
should
describe
the
behavior
of
the
code
under
test,
so
the
third
one
should
return
an
object
having
property
foo.
True,
yes,
it
does,
but
it
also
has
this
other
property
and
we'll
get
to
that
later.
But
it's
good
enough
for
now.
So
now
we
have
three
tests
and
we
run
npm
test.
Npm
tests
runs
mocha,
which
loads
this
test
file
and
we're
using
mochas
api
to
create
tests.
A
So
we've
created
three
tests
here
yay
now
I
want
to
introduce
sweets.
So
what
a
sweet
in
mocha
does
it?
It
describes
a
scenario,
a
situation,
a
use
case,
some
sort
of
context.
There
are
lots
of
words
you
could
describe
it.
It's
also
just
kind
of
a
logical
grouping
or
collection
of
tests.
You
could
think
of
it
that
way,
but
each
suite
much
like
a
test
has
a
title
string
and
this
is
required
and
it
has
a
body
function
which
is
also
required.
A
A
The
title
describes
the
suite,
describes
the
scenario
and
that
api
is
called
describe,
so
we
want
to
create
a
suite
and
give
it
a
title,
and
a
body
and
presently
in
mocha
body
is
always
synchronous.
So
I
I
failed
to
mention
before,
but
it
was
in
the
slide
that
a
test
in
mocha
can
be
asynchronous.
It
can
return
a
promise
if
you
want
to
use
node
style
error.
A
First
callbacks,
I'm
sorry
you
can
do
that
too,
but
a
suite
used
with
describe
for
now
and
is
always
synchronous
that
might
change
in
the
future,
but
you
can't
return
a
promise
from
from
a
a
described
body.
So
what
we
want
to
do
is
organize
our
tests.
Using
these
suites
and
we
want
to
wrap
the
tests
and
suites
described
in
this
scenario,
so,
for
example,
the
first
one
might
look
like
this.
A
A
And
again,
the
body
contains
a
test.
Just
we
can
just
use
the
tests
we
used
before
so
go
ahead
and
edit
bargs.spec.js
and
you
should
have
three
sweets
when
you're
done
and
run
npm
test
to
check
your
work
and
I'll
leave
this
up
for
a
second.
So
you
can
so
you
can
kind
of
copy
it
to
get.
A
A
Okay,
I
expect
you
have
that
copied
if
you
did
it
right,
it
should
look
like
this
when
you're
on
npm
test-
maybe
not
exactly
like
this,
but
similar
to
this.
A
The
when
blah
blah
is
the
title
of
the
suite
and
under
that
will
be
any
tests
in
that
suite,
and
it
should
be
indented
a
bit.
A
All
right,
so
this
is
how
we
would
make
something
like
that
happen.
So
this
is,
this
is
adding
sweets
to
our
our
tests.
A
Our
tests,
so
in
here
you're
gonna,
have
it's
pretty
simple
you
have
describe
in
that
describe
body
is,
is
your
test
that
you
had
before,
and
you
have
three
of
these
things
right,
so
you
may
have
noticed
that
when
we
did
the
tests
the
first
time
or
is
that
so
should
there
were
a
typo
and
that
doesn't
have
that's
not
very
helpful.
A
What
should
throw
a
type
error?
What
should
return
an
object,
having
property
foo,
and
this
is
what
sweets
help
you
with,
because
now
we
know
what
exactly
we're
talking
about
when
when
we,
when
we
execute
those
tests
all
right,
so
that's
so
that
gives
us
some
more
context
that
describes
the
situation
or
the
scenario,
and
that's
why
we
want
to
use
sweets.
A
So
the
next
core
concept-
and
there
are
only
really
three
three
of
these
things
you
need
to
worry
about.
There
are
three
core
concepts
here
in
mocha:
there's
the
test,
the
sweet
and
finally,
the
hook
so
hook
may
be
a
term
that
is
used
to
mean
a
lot
of
different
things,
but
in
mocha
a
hook
is
a
code
that
runs
before
all
the
tests.
A
After
all,
the
tests
before
every
test
or
after
every
test
and
a
hook
runs
in
the
context
of
sweet.
So
just
like
you
can
think
of
a
hook.
It's
essentially
just
like
a
test.
You
don't
actually
need
to
make
the
assertion
in
it,
but
the
api
is
the
same.
So
the
title
is
optional,
though
you
don't
need
to
give
give.
A
These
hook
functions
a
title,
but
they
can
be
asynchronous,
they
can
return
promises,
and
so
you
can
think
of
these
like
setup
or
tear
down
functions,
maybe
some
other
test
framework
or
or
in
another
language,
maybe
has
a
notion
of
let's.
This
is
how
we
set
up
our
tests.
This
is
the
test
harness
or
what
have
you
and
then
we
have
a
teardown
to
clean
up
afterwards,
and
so
in
this
api,
which
again
it's
a
global
api,
you
don't
need
to
require
or
import
anything.
A
Before
will
run
once
basically
before
any
of
the
tests
and
before
each
will
run
once
for
every
test,
and
so
the
order
in
which
things
happen
is,
is
this
and
maybe
I
should
have
added
a
diagram
or
something,
but
when
you
have
sweets
in
mocha
like
so
the
very
first
thing
that
happens
when
mocha
runs
this
file
is,
it
goes
and
it
finds
all
the
sweets
and
that's
like
a
depth.
First
search.
So
it
looks
for
a
describe
and
in
there
it's
it
says:
oh
okay,
I
have
it
called
it's.
A
I
have
called
a
hook.
You
can
nest
sweets,
so
maybe
there's
more
described
so
it
looks
through
all
the
describes.
Now
it
doesn't
run
any
tests,
yet
it
doesn't
run
any
hooks.
Yet
it's
just
like
mapping
it
out
and
and
getting
an
understanding
of
where
everything
goes,
and
so
that
happens
first
and
then
within
a
suite
before
will
run.
So
this
is
the
before
all
hook
after
that,
so
before
each
will
run.
A
The
after
hook
runs
okay,
most
of
the
time
you're,
probably
going
to
be
using
before
each
at
least
in
my
experience
before
is
useful,
maybe
for
if
you've
got
something
really
slow
that
you
won't
don't
want
to
do
before
every
test.
Maybe
I
don't
know
start
a
server.
I
don't
know,
but
before
isn't
used
quite
as
often,
but
before
each
is
used
often
so
what
we
want
to
do
is
we
want
to
use.
A
Hooks
to
to
make
our
tests
a
little
more
efficient
so
that
third
one
so
the
third
suite
went
past
a
single
argument:
foo,
as
I
mentioned
before-
it's
not
yes,
we're
checking
the
value
equals
a
thing,
but
we
only
check
a
single
we
when
we
described
it,
we
only
had
a
single
property.
So
what
I
want
to
do
is
split
that
up.
I
want
to
split
this,
the
test
and
the
suite
into
two
tests.
A
So
our
third
third
suite
when
passed
a
single
argument
through
it,
should
have
two
functions
in
it
or
two
tests
and
we're
going
to
test
two
separate
properties
of
of
the
return
value
here.
So
in
both
tests,
we're
calling
parse
and
we're
giving
it
dash
dash,
foo
and
an
array
in
the
first
test,
we're
making
sure
that
the
return
value
has
a
property
foo
and
that
foo
is
equal
to
true
and
then
the
second
test,
we're
making
sure
that
it
has
a
property
of
underscore
and
that's
an
empty
array.
A
A
A
So
we
want
to
add
a
before
each
hook
to
the
when
past
the
single
argument
foo
suite
and
it
prepares,
it
prepares
the
scenario
it
sets
it
up
for
the
two
tests
in
that
suite
and
below,
you
will
see
a
link
to
the
mocha
docs
on
hooks
and
it
talks
about
how
to
how
to
use
them,
but
you
wanna
before
each
hook
and
your
test
body,
so
that
would
be
the
stuff
in
so
the
stuff
in
it.
A
So
right
here
where
we
have
a
cert,
strict,
equal,
the
only
function
call
in
that
test
body
should
be
the
call
to
the
to
a
cert.
We
shouldn't
need
to
call
parse
in
the
test
body,
and
the
way
I
prefer
to
do
this
is
to
declare
a
variable
in
the
sweet
body
and
then
in
the
hook
define
that
variable,
and
there
are
other
ways
to
do
this.
You
may
prefer
one
in
the
other,
but
I
prefer
to
use
function,
scope
and
do
it
this
way.
A
A
A
Okay,
so
if
you
did
this,
you
should
see
the
same
output
you
did
before
so
we're
essentially
refactoring
into
hooks,
but
the
test
and
suite
output
should
be
the
same
as
we
had
before.
A
Maybe
not
as
we
had
before,
because
we
split
that
function
into
two
so
yeah
that
third
suite's
gonna
have
gonna
have
two
tests
in.
B
A
Okay,
so
we
need
to
kind
of
wrap
this
up,
so
this
is
what
I
would
come
up
with
to
to
to
refactor
the
sweet
to
use
hooks.
So
in
the
in
the
in
the
sweet
body.
I
want
to
declare
a
variable.
I
call
it
result.
You
can
call
it
whatever
you
want,
but
I
don't
define
it
and
so
in
before
each
I
will
define
the
variable
and
the
variable
is
the
return
value
of
passing.
A
Foo
to
parse,
and
so
we
can
use
function,
scope
here
and
because
before
each
runs
before
those
two
tests
result
will
be
defined
by
the
time
we
enter
them
and
so
below.
We
can
just
check
the
result.
We
can
look
at
result.foo.
A
Is
this
true
and
then
finally,
we
can
look
at
the
positional
arguments
again,
which
is
underscore,
and
we
can
assert
that
it
is
an
empty
array.
Now.
Remember,
remember
what
I
said
about
deep,
strict,
equal
and
strict
equal,
so
strict
equal
works
on
primitives
and
deep,
strict
equal
works
on
objects
and
an
array.
An
array
is
an
array,
but
an
array
is
also
an
object,
and
so
you
have
to
use
deep,
strict
equal.
If
you
want
to
compare
arrays.
A
A
So
that
is
how
to
use
a
hook
in
mocha,
and
you
know
before
each
again,
we'll
run
before
every
test
after
each
one
after
every
test,
there's
before
and
and
after,
and
you
can
again
check
out
the
docs
at
mocha
jsorg
to
get
more
information
about
about
how
to
use
them,
and
so
in
this
section
I
have
covered
how
to
install
mocha
how
to
run
tests
with
mocha
how
to
configure
your
package
json
to
run
mocha
when
we
call
npm
test
and
finally,
how
to
create
tests
suites
and
hooks
in
mocha
and
the
definitions
thereof,
and
I
think
that
about
does
it.
A
So
again,
my
name
is
chris
hiller.
I'm
a
developer
advocate
at
ibm
a
node.js
core
collaborator,
a
mocha,
maintainer
openjs
foundation.
Cpc
find
me
on
github
bone
skull
twitter
bone
skull
of
the
xero.
I
also
have
another
talk.
I
think
it
might
actually
be
right
after
this
one
about
tooling
and
node.js.
It's
called
possible
tools.
You
might
want
to
check
that
out.
Also
I'm
a
panelist
on
js
party,
which
is
a
fun
javascript,
centric
podcast,
and
they
are
having
some
sort
of
live
podcast
here
at
opengs.
A
World
check
out
the
schedule
for
that.
I
couldn't
tell
you
when
it
is
because
I
don't
know
where
you
live
so
yeah
time
zones
are
hard,
but
thank
you
for
for
attending
attending
this
workshop
and
I
will
be
around
for
a
few
minutes
to.