►
From YouTube: FE Pair Programming - Component unit test from scratch
Description
In this impromptu pairing session, we walk through writing a component unit test from scratch using a common approach and techniques.
B
A
So
peyton
I
don't
mind:
do
you
mind
if
I
kind
of
just
start
ranting
about
unit
testing
and
no
no
tell
me
tell
me
what
to
do
I'll,
be
the
padawan
today.
So
the
first
thing
is
the
describe
the
top
level
describe
block
what
you
put
in
your
name
there.
It's
really
really
helpful
if
this
is
globally
unique
throughout
a
whole
test
suite,
which
means,
if
I
just
throw
shared
runners
in
there,
that's
probably
not
enough
information
to
make
it
globally
unique.
A
I
personally
just
throw
in
the
import
path
of
the
subject
under
test
like
our
spec.
We
do
that
a
lot.
Yes
very
similarly.
So
on
line
two,
I
usually
just
copy
everything
after
the
teal
day,
and
I
just
throw
it
in
there
and
then
also
like
sands,
the
dot
view
and
yeah,
and
you
know
it's
kind
of
funky
because
you're
like
hey,
we're,
duplicating
the
path,
what
if
the
path
changed,
but
if
you're
looking
for
it
yeah.
A
A
No
no
yeah
well.
Well.
We
may
not
need
the
top
level
before
each.
We
will
need
the
after
each.
So
what
I
do
usually
do,
whatever
I'm
going
to
create
a
shared
variable
like
that,
that's
leaded,
I
think,
about
cleaning
it
up
first
and
so.
We're
gonna
have
to
always
do
rapper.destroy
and
then
wrap
it
up
and
then
even
more
paranoid.
It's
doing
rapper
equals
null
afterwards.
Yeah
I
mean
I
think,
you'd
want
to
flip
them
too
yeah
yep,
great
awesome,
all
right!
So.
A
A
Yeah
and
it's
important
to
like
highlight
two
while
we're
here
that
so
this
is
a
helper
function
that
helps
us
just
create
the
subject
under
test,
and
I
use
that
terminology
at
the
terminology
intentionally,
because
this
kind
of
pattern
doesn't
just
apply
just
a
few
components,
but
also
with
any
kind
of
thing.
We
were
testing
where
we
need
to
manage
the
life
cycle
of
it.
A
Encapsulating
how
we
stand
up
that
subject
is
really
helpful,
so
yeah
we'll
run
shallow
amounts,
because
this
is
a
fairly
straightforward
component.
We
don't
need
a
full
amount,
we're
going
to
set
the
the
value
of
shallow
mount
to
rapper.
It's
a
rapper
equal
shallow
amount
before
each
on
line.
Eight.
A
A
A
I
usually
put
like
some
test
constants
I
put
those
outside
to
describe
usually
so
like
outside,
to
describe
I'll,
do
something
like
const
test
under
big
caps,
test,
underscore
update
path
and
so
anywhere
else.
In
my
you
know
tests
where
I'm
wanting
to
reference
this
path,
I
don't
reference
it
by
the
magic
string.
I
just
referenced
that
thing
yeah
and
so
then,
and
then
enabled,
let's
just
have
it
be
true
by
default
yeah
and
allow
override
yep.
A
Would
say
by
default,
let's
enable
it
to
true
because
having
it
be
false,
where
everything's
disabled
and
that's
the
you
know,
looking
ahead,
that's
going
to
be
kind
of
the
edgy
case,
so
you
don't.
We
don't
have
to
put
these
props
here.
We
could
like
be
very
explicit
about
them
in
our
different
cases,
but
we
can
refactor
that
later.
B
A
Yes,
100
like
that
yep,
so
what
I
then
do
I
and
so
there's
two
different
ways
to
approach:
organizing
the
spec
and
I've
found
one
way
to
be
significantly
more
helpful
than
another
way.
Okay,
if
you
go
to
our
component,
one
might,
if
you
go
to
the
template
and
I
usually
start
testing
the
spec
by
looking
at
the
template,
one
might
be
tempted
to
say.
A
Oh,
I
want
to
describe
this
first
topic,
and
so
you
think
about
okay,
I'm
going
to
create
a
whole,
I'm
going
to
create
a
whole
a
section
of
specs
around
just
what
is
the
behavior
of
this
talk,
this
specific?
Typically,
how
I
do
it
right,
so
that's
kind
of,
I
would
say,
you're
slicing
it
based
on
the
behavior
another
way
of
slicing.
It
is
slicing
it
based
on
the
state
of
the
component.
A
So
the
way
I
normally
approach
it-
and
I
found
this
to
be
a
lot
helpful
because
that's
usually
the
hardest
part
is
setting
up
the
component
and
to
be
under
these
different
conditions.
Right
I
test
behavior
with
its,
but
with
describe
blocks.
I
group
common
set
of
components.
So
without
what
we'll
end
up
having,
if
you
go
back
to
our
underscore
spec
I'll,
usually
do
this,
I
usually
do
describe.
A
D
A
B
A
So
I'll
do
it
with
one
of
these
subscribe
groups.
The
one
thing
you
want
to
watch
out
for
is
that
and
in
all
cases
this
isn't
going
to
be
a
problem,
but
it
can
be
a
problem.
The
one
thing
you
want
to
watch
out
for
is
that
you
don't
create
a
component
twice
in
the
same
spec
or,
if
you're
feeling
really
paranoid
a
way
to
do
that
is
in
our
create
component.
I
could
do
ifrap
or
throw
in
here
sometimes
I'll.
A
Do
that
all
of
this
boilerplate
we
have
an
rfc
for
encapsulating
all
the
boilerplate,
but
since
we
don't
have
that
yet
you
know
just
depends
on
how
picky
you
want
to
be
about
it.
I
tend
to
lean
towards
being
really
picky
about
it,
because
I
just
am
generally
paranoid,
but
I
wouldn't
worry
about
it
onto
so
after
I
would
just
on
for
right
now
on
line
25
underneath
it
I
would
just
do
the
before
each
and
the
create
component.
B
B
A
Yep
yeah
you're,
100,
correct
yeah,
we'll
need
to
do
that.
So
then
I
guess
so.
Then
I
look
at
the
template
and
be
like
okay.
What's
all
the
things
I
want
to
with
the
default,
I
want
to
double
check
with
my
template,
and
one
is
so
we
don't
so
it
looks
like
we
have
a
loading
icon
and
that's
not
going
to
show
up
by
default
unless
we're
actually
doing
something.
So
I
do
want
to
probably
now
create
a
find
a
finder
for
the
loading
icon
all
right
and
we'll
probably
need
to
import
that.
A
E
B
A
A
A
E
A
B
A
A
A
A
A
I
feel
like
you,
can
do
find
loading
icon
dot
elements.
I
think
we
actually
have
a
matcher
for
this.
I
think
you
can
do
find
loading
icon
element
and
then
we
can
check
if
expect
to
be
visible.
I
think
we
have
a
matcher
for
that,
so,
instead
of
false
and
it's
like,
and
instead
of
calling
it
yeah
yeah,
it's
just
like
that,
but
we're
going
to
check
if
it's
not
to
be
visible.
B
I
mean
I
don't
I
don't
so
like
with
this
toggle
like
testing
wise,
like
I
mean
we're
going
to
be
getting
down
into
the
nitty-gritty.
If
we
say
like,
we
want
to
make
sure
that
this
toggle
is
well,
I
guess
we
could
always
check
the
ui.
I
was
thinking
about
like
checking
the
vm.
We,
of
course,
don't
want
to
do
that
to
check
if
this
value
is
set
to
true
by
default.
B
A
The
inner
functionality
of
the
toggle
button,
which
is
really
nice
because
some
of
that
isn't
going
to
be
really
easy
to
re-invent.
So
I
think
we'll
all
we
need
to
really
do
is
just
look
for
gl
toggle
components
and
we
could
do
like
a
filter
on
the
label.
So
we're
looking
by
the
label
of
like
I
want
to
see.
Hey
is
my
enabled
one:
what's
the
value
of
it
and
I
want
to
make
sure
it's
not
disabled
and
other
things,
and
we
can
do
all
of
that
kind
of
in
one
fell
swoop.
A
Yeah
and
what
I'm
kind
of
envisioning,
because
I
know
we
have
another
toggle,
it
would
be
cool
to
have
one
fine,
toggle
that
takes
in
the
label,
so
we
would
have
both
we'd
have
both
a
find,
enable
toggle,
which
actually
calls
find
toggle
with
that
specific
label
that
we're
we're
wanting
to
do
it.
But
let's
just
do
it
all
here
and
we'll
abstract
later,
if
you
call
that
so
we
want
to
yeah
import
gl
toggle.
I
guess.
B
A
Give
us
two
yep
and
then
we're
gonna
get
dot
wrappers
after
that
call,
and
then
we're
going
to
call
dot
find
that
gives
us
an
array
of
the
view
test,
detail,
wrappers
and
then
we're
going
to
find
a
specific
one
based
on
the
label
we
passed
to
it.
So
then
I
think
yeah.
So
then
we're
going
to
do-
and
I
I
like
to
just
use
x,
so
I
would
just
do
x
an
arrow
function
with
x
in
it.
Let's
not
take.
A
A
I
got
oh
okay
and
we'll
say
if
that
equals
whatever,
and
this
is
this
is
the
argument
I
would
expect
kind
of
for
this
actually
for
this
whole
line.
22,
because
right
now
we're
just
looking
for
the
enabled
toggle,
but
this
whole
block.
It
would
be
really
nice
if
we
did
the
same
thing
for
the
other
toggle.
B
A
B
A
A
A
A
A
A
E
B
B
A
Yeah
and
and
so
doing,
that
kind
of
like
index
selecting
is
that's
fine,
magic
numbers,
really,
you
know
with
zero
or
one
yeah
and
it
can.
It
can
really
mess
things
up
if
let's
say
our
first,
so
we
know
that
second
toggle
is
actually
sometimes
doesn't
exist.
Right,
let's
say
the
first
toggle
sometimes
didn't
exist
that
can
really
mess
things
up.
If
I'm
just
trying
to
say
hey
at
zero,
because
it's
sometimes
that
means
one
thing
and
another
time
it
needs
a
different
thing.
A
So
having
a
semantic
selection
is,
is
ideal
and
like
our
our
semantic
way
of
selecting
things,
that's
you
know
what
at
least
do
this
is
to
use
like
test
ids
like
do
data
test
id
or
something,
but
to
make
it
even
more
powerful
doing
stuff
based
on
labels
is
on
what
the
user
actually
sees
right
right.
That's
really
neat
yeah
and
we
can.
A
Yeah
yeah,
okay,
I
like
doing
it
like
that.
There's
other
there's
other
ways
of
there's
a
whole
rc
too
about
selecting
things
based
on
text
versus
ids
yeah,
using
testing
the
the
testing
library
package.
But
I
don't
think
that
plays
with
view
test
details.
I
think
that's
just
dom
selection,
which
is
since
we're
messing
with
the
toggle,
and
that
has
a
lot
of
implementation
details
with
it.
B
B
A
I
may
miss
like
the
natural
organization
of
some
of
just
the
very
simple
parts
and
then
okay,
let's
do
the
more
hard
to
test
places
and
see
where
they
best
fit,
but
yeah.
Let's,
let's,
let's
keep
going
and
you
may
you
may
find
out
and
that's
not
to
say,
like
this
approach
is
the
only
approach
to
do
testing.
This
is
just
what
I
found
really
helpful
to.
D
A
B
A
B
B
A
B
A
In
the
spec,
that's
a
great
that's
a
great
point.
We
could
even
move
the
labels
up
to
the
constants
and
now
we're
both
referencing
the
same
labels
like
both
the
production
code
and
the
test
like
I
don't
even
have
to
duplicate
these.
That's
one
approach.
We
could
use
test
ids
if
we
felt
like
that.
That
was
more
helpful,
since
this
is
just
a
one-liner
function
like
I'm
25
and
24
yeah.
I
think
it's
it's
kind
of.
Yes,
it's
still
kind
of
fine,
but
yeah.
I
think
it's.
A
A
A
Yeah,
it
doesn't
give
us
an
empty
wrapper.
It
gives
us
a
null,
so
we
would
expect
this
to
be.
No.
If
we
don't
like
that,
what
we
could
do
is
is
change
our
fine
toggle
to
actually
return
like
an
empty
rapper
like
we
could
do.
You
know
wrappers
up,
find
or
an
empty
rapper,
so
we're,
but
that's
kind
of
over
engineering.
B
A
A
B
B
A
A
A
B
D
A
A
A
I
like
to
be
I
personally
like
to
be
really
terse,
so
I
prefer
having
not
a
lot
of
words
but
whatever,
whatever
floats
your
boat
man,
but
it's
gonna,
it'll
take
in
a
toggle
or
it'll
take
in
a
a
which
is
actually
a
view
test.
Details
wrapper
and
I
think
we're
gonna
have
to
do
so.
Going
back
to
the
component.
A
I
think
it's
gonna
be
change.
I
think
that's
what
we're
going
to
need
to
admit
access
and
input
yeah,
and
I
think
it's
not.
We
can't
actually
do
trigger
because
trigger
triggers
the
native
dom
event
when
we
actually
just
need
to
do
vm.emit,
we
need
we
need
to
trigger
the
the
view
thing
yeah
and
so
then
we're
going
to
do
change
and
then
I'm
not,
and
then
I
think
we
say
what
value
we
want
to
be
too.
A
Yeah
it'd
be
something
like
that,
so
what
we're
going
to
now
do
is
with
the
default,
but
now
we
have
a
whole
new
context
of
okay.
We've
done
our
d.
We've
we've
mounted
everything
as
a
default,
and
I
would
actually
put
this
inside
the
default
one.
We
could
do
it,
we
could
do
it
outside
and
I
think
it
actually
makes
a
lot
of
sense
too,
because
that
I
like
keeping
things
flatter
than
more
and
more
nested.
So
that's
a
good
call,
so
I
would
call
this
yeah.
B
A
So
I
mean
we:
have
it
all
encapsulated
one
function,
so
it's
not
it's
not
a
big
deal.
If
we
we
call
that
function
twice,
but
now.
What
we
need
to
do,
though,
is
probably
check
that
the
and
the
before
each
let's
call,
let's,
let's
trigger
our
new
function,
the
change
toggle
thing
really
for
each
because
that's
our
new,
that's
our
new
state
is
when
the
user
does
this
thing
we're
going
to
do
a
new.
A
A
A
B
A
A
A
A
B
A
Yeah
well,
let's,
let's
do
it!
So:
let's
import
x,
mock,
axios,
adapter,
always
forget
the
name.
You
had
it
right.
It
was
big
m.
We
usually
call
it
mock,
axios
big,
a
adapter
from
and
then
I
think
it's
actually
little
a
axios
dash
or
no
it's
no!
It's!
No!
It's
not
it's!
Oh
that
is
it
yep,
sweet,
okay,
okay,.
A
A
I
like
under
different
context,
if
I
needed
to-
and
so
that's
that's
one
pattern
I
do
com
almost
consistently
is
collaborators
are
always
setting
them
up
in
the
top
level
before
each.
If
you
couple
them
to
the
create
component
thing,
it's
you're,
gonna,
nine
times
out
of
ten,
it
makes
tests
way
more
complicated
than
they
need
to
be
so
just
setting
up
the
collaborators
here
and
then
tweaking
them
is
a
lot
more
simpler
of
approach.
A
In
my
opinion,
like
so
some
people
like
set
up
the
store
and
stuff
all
inside
of
create
component
and
in
my
opinion,
that
makes
some
of
your
tests
just
really
hard
to
manage,
because
I
don't
necessarily
get
to
tweak
my
store
before
I
create
my
component
like
sometimes
that's
really
really
helpful.
It
makes
things
a
lot
simpler.
So
that's
a
really
good
point.
A
Yeah,
so
so
not
making
sure
that
create
component
doesn't
do
too
much,
that's
just
responsible
for
creating
the
subject
under
test,
but
then
collaborators
setting
up
collaborators-
I
could
do
all
those
individually,
but
we
just
create
all
of
them
on
the
top
level
before
each
yeah.
So
let's,
let's
do
that
for
this
mock
axios
adopt
after
and
the
before,
each
so
mock
equals
new
mock,
axios
adapter.
A
A
A
A
A
A
A
A
Yeah
that
sounds
good.
Okay,
anytime,
we
create
a
shared
thing
in
our
spec.
I
would
always
make
sure
we
clean
it
up
properly,
so
I
would
start
with
the
after
each.
We
should
probably
just
null
it
out
so
that
we
don't
potentially
run
into
an
issue
where
we're
resolving
something
that
doesn't
exist
anymore.
A
A
B
A
B
A
The
second
parameter
is
going
to
be
the
callback
function
or
oh,
wait.
Wait!
Wait!
Oh
you're
right!
I'm
messing
something
up,
you're
right,
it's
not
the
second
parameter.
We
do
mock
on
post,
close
parentheses
and
then
we
do
dot
reply
and
we're
gonna
pass.
This
whole
arrow
function
thing
to
the
dot
reply,
you're
right,
so
we're
gonna.
A
A
A
I'm
following
yeah
yeah,
that's
all
that's
all
I
want
to
do
we'll
actually
just
call
resolve
requests
and
if
we
wanted
to
reject
it
like
we
could
figure
out
a
way
to
save
it
and
save
both
of
those
out
in
a
nice
way.
But
let's
just
keep
it
simple
for
right
now:
oh
you're,
right
yeah.
We
can't
just
call
since
we're
actually
assigning
resolve
to
that.
C
A
Okay
yeah,
so
let's,
let's
keep
going.
We
should
now
not
have
our
failure
anymore
yeah,
because
we
knocked
it
out
and
I
missed
it
there
we
go
cool
yeah,
sweet
great,
so
we
should
that
thing
should
be
existing.
Now,
that's
great!
We
should
be
loading
now
like
we
should
have
made
our
requests.
So
it'd
be
great
for
us
now
to
assert
that
we
did
make
our
request.
A
I'm
trying
to
think
of
correct
payload,
but
yeah
there's
there's
a
number
of
different
ways.
We
could
do
that
to
get
the
payload
that
we
made.
The
request
with
one
way
is
to
look
at
you
can
get
like
the
hiss
there's
like
a
history
prop
that
mock
axios
adapter
keeps
track
of.
When
we
see
the
history
of
all
the
requests
we
made,
we
might
like
doing
it
that
way.
Another
way
is.
B
A
A
Endpoint
with
correct
payload
that
sounds
incredibly
descriptive
and
helpful
to
me:
yes
and
I'm
not
being
sarcastic
okay,
yeah,
so
I'm
pretty
sure
while
we're
here,
let's
just
console.log
mock.history
like
that's,
that's
where
it's
it's
stored
somewhere.
This
is
the
function
or
just
a
property
on
it.
Yeah.
A
A
A
But
but
it's,
but
this
is
a
totally
good.
This
is
totally
fine
approach.
I
would
suggest
you
know
right
now
we're
kind
of
talking
about
how
do
we
hit
the
same
thing?
Two
different
ways:
let's
just
create
another
helper
for
this
and
say,
like
you
know,
find
request,
payload
and
and-
and
we
can
figure
out
the
way
to
do
it
there
or
maybe
like
a
git
request
payload
because
you're
not
necessarily
finding
it
in
the
dom.
However,
you
want
to
do
it.
A
B
A
D
A
B
A
A
If
I
was
really
concerned,
if
I
was
concerned
about
like
okay,
I
want
to
capture
what
it
is,
but
I
also
really
want
it
to
be.
This
make
sure
it's
the
same
under
these
different
specs,
I
would
consider
moving
it
to
another
variable,
but
this
this
is
like
the
super
readable,
because
you
can
also
looking
at
docs
or
looking
at
tests,
also
like
a
documentation
of
its
behavior
like
this.
This
this
is
still
really
readable
of
when
something
happens.
What
do
I
expect?
Why
have
I
never
heard
of
this.
B
A
A
Another
thing,
though,
too,
that
we
want
to
we
want
to
confirm
is
that
the
toggles
are
disabled,
because
that's
something
we
do
when
we're
loading
as
well.
So
so
right
now
we're
in
our
special
loading
state
that
we
want
to
make
sure
we
show
the
loading
icon
and
that
our
toggles
are
both
our
toggles
are
disabled.
So
I
would,
I
would
have.
A
A
We
can
double
ch,
I'm
sorry,
I'm
I'm
tripping
over
myself,
you're,
fine,
we'll
we'll
get
to
that,
and
I
think
we'll
be
able
to
write
that
test,
really
easy
and
that's
one
thing
cool
when
we
start
creating
helpers
for
these
things,
even
though
we
haven't
duplicate
ourselves,
but
just
for
readability
yeah,
it
helps
us
add
more
specs,
really
easy
yeah!
That's
what.
B
A
A
A
C
B
I've
gotten
to
where
I
just
like
named
stuff.
I
used
to
spend
a
lot
of
time.
You
know
thinking
about
naming
oh
yeah,
I
even
saw
on
twitter
the
other
day
someone
asked
if
you
were
building
a
component
blah
blah
blah
like
it
might
gave
like
an
example
of
the
component.
What
would
you
name
it
and
I
was
like
just
name
it?
Something.
A
So
when
react
was
first
coming
out,
we
were
kind
of
thinking
of
doing
single,
page
apps,
our
our
our
company.
We
were
like
building
our
built,
our
own
single
page,
app
library,
and
I
was
really
pushing
for
it
and
I
called
it
spage
for
a
single
page
that
was
yeah,
so
that
kind
of
like
really
weird
esoteric
naming
I'm
such
a
huge
fan
of
like
the
gulp
library.
Do
you
remember
using
gulp?
Oh
yes,
yes
and
power
was
the
other
one
or
yeah
open
bauer.
A
Yeah
you're
asking
a
really
good
question,
so
the
2b
visible
matcher
that
that
special
matcher
or
not
well,
no,
it
should
work
that
way,
but
I
I
wonder
if
it's
maybe
it's
not
visible,
let's
console
log
the
element
and
maybe
our
master
isn't
doing
what
we
really
think.
It's
doing.
Do
you
ever
do
this?
For
this
case?
A
A
A
A
B
A
B
A
A
A
C
A
A
A
A
E
A
F
A
D
B
A
B
A
A
A
A
A
A
A
A
A
B
A
A
A
B
A
Are
still
disabled,
disabled
right
what's
happening?
Is
I'm
I'm
recreating
the
wheel
of
mock
axios
adapter
already
lets
us
mock
the
response,
so
maybe
we
need
to
not
try
to
add
our
own
mocking
thing
around
it
and,
let's
just
embrace
that,
so
I
would
say:
let's
get
rid
of
resolve
request
and
I
would
say:
yeah,
let's,
let's,
let's
just
yep,
just
like
that,
but
then
in
my
different
context
that
needs
something
special.
A
B
A
A
E
A
A
A
A
B
A
A
A
A
A
No,
so
we're
not
airing
out,
I
guess
we're
just
not
waiting
and
long
enough.
So,
let's,
let's
try
this
out.
If
we
go
down
before
we
do
next
tick,
let's
I
would
suggest
let's
go
ahead
and
make
this
an
async
callback
function,
because
I
think
we're
going
to
do
another
weight
yeah.
I
think
we
want
to
do
yep
and
before
the
next
pick,
I
think
we
want
to
do
a
weight
on
line
99..
D
D
A
Yeah,
so
here's
the
scary
thing
like
have
you
seen
what
wait
for
promises
actually
is
I've
used
it
a
ton
but
never
looked
at
the
implementation
yeah
if
you
dive
into
it,
it's
like
it
like
just
calls
like
request,
animation
frame
or
something.
So
it's
like.
It's
not
determined
it's
a
timeout
or
something
it's
yeah.
It's
not
it's!
Not
it's
not
deterministic,
which
is
a
little
scary,
but
maybe
it's
kind
of
deterministic.
A
A
What
we
could
do
is
actually
emit
an
event
from
here
like
on
our
like
on
a
final
or
something,
and
just
like
we
kind
of
have
test
ids.
These
are
kind
of
like
test
events
that
help
us
know.
Okay,
I'm!
I
can
now
start
asserting
things
because
we've
we've
finished
whatever
processing
we're
trying
to
do
interesting,
but
that's
another
thing
I
would
do
as
a
last
resort.
So
do
we
have
anything
like
that
implemented
anywhere?
A
We've
done
it
a
couple
times
because
it's
come
up
where
wait
for
promises
was
flaky,
and
so
the
way
to
deterministically
wait
for
something
we
expect
is
to
have
a
semantic
event,
and
that's
when
I
would
recommend
doing
it
so,
like
a
dot.
Finally,
and
then
like
you,
you
emit
a
view
event
yeah,
that's
that's
that's
the
thing
I'll
have
to
do
a
grip
of
the
code
base
and
look
at
that
later.
A
A
A
A
D
D
A
I
don't
know
it's
going
to
be
called
with,
so
let's
just
pass
in
something
and
then
see
what
it
would
would
have
been.
It'd
be
nice
to
also
capture
the
message.
So,
let's
yeah
that's
what
I
was
thinking
like
since:
don't
we
don't
we
throw
a
message
in
the
catch
yeah?
I
think
we
have
something
like
that,
but
it
looks
like
we
can
also
get
something
from
like
our
response.
So
I
think
we
could
do
both
with
the
parameterized
spec.
Let's
do
that
in
a
second,
but
let's,
let's
just
double
check
here.
A
A
A
C
A
That's
fine.
It's
nice
sometimes
seeing
those
errors-
yeah,
okay,
maybe
it's
nice.
Maybe
we
should
console
log.
It
console
error
of
the
error,
but
let's
whatever
yeah
okay.
But
if
you
go
back
to
our
component,
you
see
there's
actually
a
condition
here.
If
our
error
has
response
data
error,
we
use
that
as
the
message.
A
A
D
A
B
A
A
A
Object
or
the
message
so
there's
two
parameters
to
this
spec,
and
so
the
first
one
is
where,
if
error
object
is
empty
and
that's
what
and
this
air
object
is
going
to
be
what
we
send
to
line
116.,
that's
what
that
condition
is
based
off
of
do.
We
have
an
error,
object
or
not,
and
that's
gonna
change
our
message.
A
So
you
could
use
that
language,
and
I
I
usually
do
that
where
I'll
say
like
expected
message,
because
so
everything
here's
all
of
my
inputs
and
then
this
is
what
I
expect
my
values
to
be,
and
so
what's
really
cool
is
then
you
just
look
in
one
table:
here's
the
behavior
of
my
component,
given
these
inputs,
these
are
the
outputs
and
it'll
make
more
sense,
as
we
start
diving
into
it.
For
now.
Let's
just
call
it
this
because
it
seems
person
might
be
nice,
the
weird
the
one
weird
thing
with
this
whole
syntax.
A
A
I
got
you
yeah
yeah
and
so
the
first
one's
gonna
be
empty.
So
we'll
just
do
curlys
just
empty.
Is
this
going
to
be
an
empty
object
so
inside
the
dollar
curly
we're
going
to
do
yep
and
then
go
ahead
and
get
out
of
it
pipe
and
the
message
is
gonna
be
line,
we're
gonna
do
dollar
curly
again
and
then
it's
gonna
be
line
127.
That
message.
A
D
A
It's
okay,
but
then
for
these
parameterized
specs
I
usually
include
the
input
as
part
of
the
name.
So
what
I'll
do
is,
after
with
error
I'll
do
space
and
then
dollar
error
opt
and
it's
going
to
inject
it.
It
doesn't
need
curlies.
I
don't
think
it.
I
don't
think.
It'll
work
with
curly's,
because
we're
technically
inside
of
like
jest
has
is
how
they
like
template
their
descriptions
or
whatever.
So
it's
going
to
be
just
error,
the
name
of
our
first
paragraph
or
yeah
yeah
great.
A
So
then
this
class
and
template
literals
really
so
that
spits
out
just
like
that.
Yeah.
It's
going
to
work
like
this.
If
you
do
an
actual,
if
you
do
an
actual
like
back
tick,
little
string
here,
error
object
isn't
in
scope.
So
it's
like
just
evaluates
for
every
parameter,
we're
going
to
evaluate
a
new
description.
A
A
This
line
right
here,
yeah
the
whole
line,
let's
copy
it,
okay
make
a
new
use
case
yep,
and
so,
if
we
go
to
back
to
the
component,
what
it's
actually
looking
for
it
looks
like
I
guess
we
want
to
go
to
if
it
has
an
error.
Prop
is
what
we're
interested
in.
So
if
we,
I
think
it's
just
error,
throw
an
error
like
this,
and
let's
just
call
it
something
like
lorem
ipsum,
whatever.
A
B
Right,
because,
if
this
okay
yeah,
so
if
this
resolves
true,
first
we're
going
to
show
this
okay,
I'm
seeing
how
this
is
tying
in
okay,
there
we
go
okay,
so
each
time
this
describe
each
it
cycles
through
the
each
statement.
So
how
do
you
keep
them
like
separated
to
like
test
each
use
case
so
it'll
describe
each
is
going.
A
To
go
through
each
line,
which
is
a
group
of
print
with
which
is
a
set
of
parameters,
so
each
line,
you
can
call
a
test
case
and
here's
the
parameters
for
each
test
case.
So
what
we
want
to
do
is
here
in
line
115.
Our
message
is
different:
it's
not
an
error.
Credible
updating
configuration,
it's
undefined
error,
so
we
want
to
update
on
line
115
the
second
column
for
message.
A
B
A
Okay,
but
you
can
also
like
you,
don't
you
can
you
can
save
yourself
some
some
brain
power
by
just
letting
the
terminal
tell
you
what
to
do.
If
you
go
back
to
our
yeah,
exactly
like
that,
but
yeah,
so
there
you
go
so
we've
got
those
two
cases
tested
great
yeah,
that's
great,
and
so
now
there's
only
one
last
thing
for
us
to
test.
I
think
we're
completely
done.
It
only
took
maybe
an
hour
hour
and
a
half.
F
B
A
B
A
A
A
A
And
it's
a
super
like
using
each
is
a
super
flexible,
super,
flexible
tool.
You
can
obviously
like
parameterize
things
in
a
way
that
just
makes
it
more
confusing,
but
for
some
cases,
if
you
can
end
up
getting
it
very
readable,
seeing
one
list
of
you
know
input
output
is
super
helpful,
yeah
yeah,
especially
for
that
function.
A
A
A
B
A
A
E
E
C
E
A
Yep,
so
in
line
77,
so
now,
let's
replace
our
specific
values
with
the
parameters
we're
going
to
call
toggle
button,
and
what
I
was
saying
earlier
is:
this
is
a
function,
so
I
I
usually
like
to
like
throw
in
like
fn
or
something
to
say,
oh,
like
on
the
name
of
the
prop
yeah.
However,
you
want
to
do
it,
it's
kind
of
fine
how
it
is
right.
Now,
oh
okay,
it's
up
to
you!
No!
That.
B
B
A
So
then
yep
that'll
be
that
yeah
and
and
so
it
should
actually
all
be
working
now,
yeah
yep,
it's
still
working
so
now.
Let's
add
another
case:
yeah,
okay,
cool.
So
the
other
case
is
you
have
to
change
the
props
for
like,
and
it's
enabled
is
already
it's
false.
Yep
yep!
That's
right!
So
then
we
just
say:
init.
A
I
would
say
so
yeah,
but
but
but
now,
actually
you
know
what
you're
doing
is
actually
you're
doing
something
like
combinatorial
testing.
Now,
where
I
have
these
two
different
values,
let
me
make
sure
I
test
all
the
different
combinations
and
permutations
of
these
of
these
arguments,
and
so
that's
one
way
of
looking
at
it
is
like
you're
right
with
this
prop
false.
A
Let's
test,
when
the
toggle
button
I
hit
is
fine
enabled,
but
let's
also
test
it
when
the
override
button
as
well
like,
and
then
you
want
to
do
it
for
each
one
of
these
different
permutations
of
values.
That's
one
thing
that
I
really
like
about
this
format
that
jumps
out
at
you
is
like.
Okay,
have
I
tested
all
my
combinations.
A
B
A
A
A
A
A
A
A
B
B
A
A
A
You
do
this
right
here,
yes,
yeah,
sometimes
if
and
we
might
actually
end
up
doing
that
because
yeah
because
it
because
technically
we've
hard
coded
enabled
there,
but
that's
actually
based
on
a
prop.
So
I
wonder
what
happens
if
we
actually
put
the
dollar?
What
if
we
replace
enabled
on
line
75
with
toggle
button
fn?
What
does
that
look
like?
A
Yeah,
oh
well,
you
just
said
it
rocks
that's
great
because
because
the
other
thing
I
was
really
hoping
to
test
too
is,
if
we
go
back
to
line
72
it'd,
be
great
to
do
that.
That
case
all
over
again,
but
with
the
other
toggle
it'd,
be
great
to
do
this
initial
case
with
the
over
override
toggle
yeah
is.
A
A
A
A
Works
all
right
say
we're
at
a
good
stopping
point,
yeah
the
the
only
and
if
we
were
willing
to
put
this
a
hundred
percent.
Yes,
we
should
stop
the
the
final
missing
piece
is
we
haven't
tested
the
component
under
the
parent
has
not
allowed
override
problem,
that's
going
to
be
just
its
own
describe
and
there's
no
parameterization
there.
So
it
should
be
really
straightforward,
but
then
we're
then
then
all
of
this
is
good
and
it's
ready
to
go.
I
think
we
just
then
want
to
do
some
manual
testing
of
it.
A
So
if
you
want
to
push
it
up-
and
you
can
ask
me
to
do
a
quick
look
over,
then
we
can
pass
it
to
another
maintainer
that
wasn't
as
involved
in
it
for
our
handbook
and
oh
yeah,
yeah
yeah
totally
totally,
and
then
we
should
be.
We
should
be
good
to
go
so
yeah,
that's
it
yeah.
The
refactor
was
yeah,
pretty
easy,
not
bad.