►
Description
Full Stack Testing with Node.js - Stacy Kirk, Quality Works
As the popularity of Node.js continues to increase, so does the complexity and scale of the applications created. With the increasing number of enterprise deployments, the need for a comprehensive full stack testing strategy becomes even more critical. More than other technologies, this environment has valuable modules to promote test-driven development and integrated testing. Developers and testers can benefit from these tools and technologies to simplify their testing, speed up their test time, and have a lot of fun at the same time.
The NodeJS community has set a great standard for developing unit tests and measuring code coverage. Even so, there are many levels of testing that need to be considered from unit, performance, API, to the front-end testing. Learn the best testing practices, process, tools, and modules to develop a continuous, integrated, full stack test solution for your next Node.js application. With organizations like PayPal, Walmart, Netflix, and LinkedIn leveraging Node.js at an enterprise level, it’s clear that a full stack test strategy is a must. This presentation will make sure that you are aware of some of the latest techniques to quickly deliver high quality test results for Node.js.
About Stacy Kirk
As a software QA architect, agile coach, coder, and speaker, Stacy Kirk has championed for quality and process innovation in software development for over 20 years. She has led global IT teams to deliver cutting-edge web, mobile, and enterprise applications in the entertainment, security, advertising, finance, healthcare, and telecom industries. As the founder and CEO of QualityWorks Consulting Group and nodeqa.io, her international firm has quickly grown to become a global leader in DevOps best practices in Quality Assurance. Her highly technical team of consultants creates products, tools, processes, and frameworks that enable businesses to accelerate software delivery. Their services include manual and automated testing services of web and mobile applications with a specialty in designing Continuous Delivery (CD) automation frameworks for performance, database, API, and mobile test efficiency.
A
A
So
how
many
of
you
have
seen
the
testing
pyramid
before
that
look
familiar
so
testing
pyramid
represents
the
quote:
unquote:
ideal
distribution
of
test
cases,
starting
with
unit
test
being
the
majority
of
your
testing,
followed
by
API
and
integration
test,
automated
UI
and
functional
tests,
and
as
little
as
possible
having
manual
tests.
So
today,
I'm
going
to
talk
to
you
about
full
stack
testing.
A
So
I
want
to
talk
a
little
bit
about
the
challenges
of
test
automation.
Maybe
some
of
you
have
said
this
before
thought.
This
heard
other
people
say
it
doing
test
automation
can
be
challenging
because
some
of
the
teams,
the
QA
developers
or
the
automation
developers
use
one
technology.
The
application
developers
use
another.
The
tests
are
time-consuming
many
times
you
hear
people
say:
oh
I,
don't
have
time
to
write
all
of
those
tests,
we're
already
up
against
a
deadline
or
they're
hard
to
maintain
and
they're
very
fragile.
A
We
make
one
change
to
the
UI
and
they're
all
broken,
or
can
we
just
get
away
with
unit
testing
I
mean
that's
the
core,
we're
testing
the
logic.
Why
do
we
need
front-end
test
or
reliability?
We
see
too
many
Reds.
We
see
too
many
failures.
We
don't
really
know
what
they
mean.
It's
just
a
waste
of
time,
even
though
we
know
it's
important.
We
just
don't
have
the
time
to
do
it,
because
there's
too
many
challenges
well,
no
genius
makes
it
a
lot
easier.
A
I
was
introduced
to
it
10
five
years
ago
and
I
realized
this
there's
just
so
many
opportunities
with
our
community
of
no
developers
that
are
excited
about
quality
and
the
open
source
community
and
all
the
feedback
just
makes
it
a
lot
easier.
So
I'm
going
to
go
through
a
few
of
the
tools.
These
are
tools
that
my
companies
leverage,
there's
so
many
out
there,
but
these
are
some
of
the
most
known
Nightwatch.
One
of
our
favorite
and
you'll
see
some
examples
and
some
of
the
code
that
I
provide
today
Nightwatch
is
a
great
test
framework.
A
It's
very
easy
to
use,
then
get
started
with
phantom
Jas.
Leverage
with
Casper
is
a
great
headless
browser
solution.
Chakram,
which
will
also
show
today,
has
a
great
rest
api.
It
is
a
great
REST,
API
test
framework,
webdriver
dot
IO
with
appium
and
mocha,
is
a
great
solution
for
mobile
automation.
Testing
in
turn,
do
which
is
one
of
the
newer
test
frameworks
is
really
supposed
to
be
the
end-all
be-all
of
automation,
frameworks.
It
tries
to
cover
all
of
the
full
stack
of
testing,
it's
still
still
new
and
getting
there.
A
But
it's
supposed
to
be
it's
good
good
enough
to
bring
you
your
coffee
at
the
end,
so
we'll
see
if
it's
able
to
achieve
that
mocha
we're
mostly
if
you've
been
doing
any
development
for
a
while,
you
probably
are
familiar
with
mocha.
It's
a
very
easy
to
use
test
framework
integrated
well
with
IDE
s,
jasmine
well
known
for
behavior-driven
development,
automation,
development,
karma
works
very
well
with
angular
and
quality
watcher
IO,
which
is
a
test
reporter
that
integrates
with
nodejs
modules.
A
So
those
are
just
a
few
there's
tons
out
there
and
I'm
always
asked
what
do
you
think
of
this?
This
test
framework
and
there's
so
many
to
choose
from
you've
got
to
figure
out
which
one
is
the
best
for
your
application,
but
these
are
some
of
the
ones
that
have
a
lot
of
feedback
and
community
involvement
online.
A
So
I
want
to
talk
to
you
a
little
bit
about
some
best
practices
to
make
things
easier
for
your
organization,
for
you
or
from
some
of
your
QA
team
teams,
to
get
a
jumpstart
on
automation.
The
first
is
integrating
your
tests
into
the
test
directory.
So
if
you
create
unit
tests-
hopefully
so
you
some
of
you
here-
do,
if
you
create
unit
tests
under
the
test
directory,
there's
probably
something
in
there.
Hopefully
it's
not
empty,
but
really
we
want
to
take
that
to
the
next
level.
A
We
want
to
have
all
of
our
tests
in
one
location.
This
is
great
because
it
allows
you
to
take
your
modules
and
if
they
are
transitioned
to
another
team
and
Department,
they
are
able
to
leverage
not
only
your
unit
tests,
but
your
performance
tests,
your
API
tests,
your
UI
functional
tests,
all
in
one
location,
and
they
can
share
the
data.
A
When
it
comes
to
getting
started
with
API
testing
people,
you
know
it
can
be
a
little
bit
tricky,
but
what
I
recommend
is
start
simple.
Make
it
very
easy
on
yourself
this
leverages,
mocha
and
chakrams.
You
can
see
it's
very
simple,
very
simple
code.
It's
just
doing
a
get
request
and
you're
validating
that
you
get
a
200
response,
it's
better
to
start
simple
and
to
create
a
favorite
framework,
even
if
it
only
does
a
validation
of
200
requests
and
then
build
on
it.
A
We'll
do
all
of
that
validation
pretty
much
in
one
line
you
can
take
it
then,
to
the
next
level,
which
is
data-driven
testing
and
and
instead
of
having
your
API
test,
one
request.
At
a
time,
you
can
leverage
a
data
file
using
the
data
driven
module
to
put
all
of
the
data
that
you
want
to
iterate
through
and
now
with
just
a
small
snippet
of
code.
You
could
go
through
hundreds
or
thousands
different
scenarios
of
requests
to
test
your
API.
A
Another
best
practice
is
using
page
object,
design
patterns.
So
for
those
of
you
that
aren't
aware,
sometimes
I
sees
I've
seen
some
people
be
shocked,
like
oh
all,
donation,
team,
automation,
team
uses
design
patterns-
oh
I,
didn't
know
that
so
one
of
one
great
best
practice
in
paid
job
design
patterns,
is
to
separate
your
test
code
or
the
tests
for
your
automation
from
the
page
elements
that
you
need
to
define.
This
separation
allows
for
changes
to
the
UI
to
not
impact
your
tests.
A
So
there's
a
gentlemanly
Alaskans
he's
an
automation
specialist
with
labs,
and
he
gives
an
example
of
where
they
had
2,500
tests
and
there
was
a
90
percent
rewrite
of
the
UI
and
they
were
able
to
recode
and
update
all
of
their
tests
in
two
days
because
they
use
page
object
design
patterns.
It
allows
you
to
really
be
able
to
keep
up
with
development
and
keep
up
with
the
UI
changes
and
not
have
as
much
breakage
in
your
automation.
A
Another
recommendation-
and
this
is
I-
recommend
this
for
developers.
All
the
time
is
when
you
are
creating.
If
your
front-end
and
you're
creating
front-end
pages,
really
consider
designing
your
pages
with
automation
in
mind,
if
you
look
at
some
of
these
examples,
the
ones
in
blue
those
are
those
are
the
locators
that
we
needed
to
find
data
on
a
page.
A
So
one
of
our
clients
had
a
site
and
we
needed
to
be
able
to
validate
a
piece
of
information
and
it
could
it
took
hours
to
be
able
to
find
the
best
way
to
identify
an
element
on
a
page.
But
if
it
was
designed
with
automation
in
mind
and
our
developer,
either
used
an
ID
or
class
name
or
an
attribute.
It
would
take
seconds
for
us
to
be
able
to
identify
that
information
and
be
able
to
write
our
automation
time.
Our
automation
code
100
times
faster,
as
you
can
see,
from
the
ones
in
the
blue.
A
You
don't
want
to
write
your
code.
You
don't
want
to
write
your
automation
code
where
you're
using
identifiers
or
locations
that
are
positional
and
you'll,
see
if
you
have
to
look
at
a
table,
if
you,
if
you're
requesting
a
table,
those
are
positional
and
if
the
UI
changes
and
it's
connected
to
a
table,
you're
gonna,
your
automation
is
going
to
break.
If
you
use
identifiers,
it
doesn't
matter.
For
example,
if
you
have
identifiers
for
a
button,
it
doesn't
matter
where
you
move
that
button,
your
automation
will
maintain,
be
maintained
and
stay
intact.
I.
A
A
A
It's
very
straightforward,
you're,
going
to
a
site,
your
yourse
waiting
for
an
element
that
you
that
you
need
to
verify
the
value
you're
going
to
verify
it
very
simple,
very
straightforward,
it's
a
great
starting
point
and
then
from
there
you
can,
you
can
add
to
it
by
leveraging
data
driven
testing,
do
the
same
thing
that
you
did
in
the
first
test,
but
now
you
can
do
it
for
as
many
different
options
and
variables
and
combinations
that
you'd
want
to
do.
The
same
holds
true
for
mobile
testing.
A
There's
still
a
list
I
know
mobile
testing
it
seen
is
not
where
browser
automated
testing
is
yet,
but
there's
definitely
still
an
easy
way
to
get
started.
We
recommend
mocha
with
webdriver,
webdriver
IO
and
a
PM
is
a
good
combination.
I
think
this
area
is
still
developing,
but
it's
a
great
it's
a
great
solution
right
now
to
get
started
and
be
able
to
create
some
mobile,
automated
tests.
We
really
trying
to
move
away
from
the
testing
that
you
kind
of
see
in
this
video
of
doing
things
manually
and
I.
A
A
People
think
everything
is
a
bug,
but
we
all
know
that
there's
so
many
different
factors
that
come
into
place
and
if
you
look
at
this
result,
these
these
historic,
this
histogram
right
here,
you'll
see
that
there's
consistency
until
around
March
and
then
there
was
something
erratic
going
on
this
isn't
and
many
times
we
don't
have
this
type
of
data
people
go.
I
told
you
that
automated
test
framework
was
terrible
or
it
wasn't
stable
or
I
knew
the
code
was
bad.
A
But
what
really
happened
was
the
servers
were
down
and
that
wasn't
stable,
so
you're
able
to
use?
If
you
have
a
test
when
you're
running
it
consistently
over
time,
you
get
the
opportunity
to
share
with
a
larger
group
the
the
improvements
that
are
being
made
and
also
fine
and
learn
what
other
issues
are
playing
into
your
continuous
delivery
and
continuous
integration
environment
and,
last
but
not
least,
we
can't
forget
about
performance
performance
testing.
You
know,
historically,
has
been
at
the
end
of
the
application
lifecycle.
It's
done.
A
We
want
to
get
all
the
other
code
in
and
then
we
test
it
well.
We
can't
do
that
anymore.
We
have
to
be
able
to,
inter
tively,
understand
the
performance
of
our
projects,
products
as
we
are
creating
them,
and
it's
easy
enough
to
do.
There
are
tools
out
there
and
I
named
of
the
few
that
we've
used,
that
you
can
integrate
right
into
your
daily
tests.
A
Every
time
your
tests
run,
you
can
get
your
performance
numbers,
you
can
collect
them
over
time
and
and
performance
numbers
are
the
kind
of
thing
where
you
need
to
have
a
benchmark.
You
have
to
look
at
it
over
time
to
really
understand
if
I
give
results
to
I've
given
results
to
a
client
and
said:
here's,
your
here's,
your
performance,
numbers
and
I
go.
A
A
If
you
run
your
tests
every
day,
even
if
there
isn't
a
code
change
that
allows
you
to
make
sure
that
your
environment
stable
and
that
there
are
no
other
factors
in
place,
it's
free
to
run
run
as
often
as
you
possibly
can
make
sure
that
there
is
some
dashboard
that
is
available
to
leadership
into
your
team
to
understand.
What's
going
on
with
quality
it'll
allow
your
team
to
come
up
with
ideas
on
how
to
do
this
better
and
embrace
failures.
I've
said
it's
getting
red
and
seeing
failures,
it's
a
beautiful
thing!
That's
how
we
learn!
A
A
So
I've
listed
some
best
practices,
but
there's
more
in
terms
of
how
do
you
get
your
organization
to
a
point
where
it
is
continuously
thinking
about
quality
and
I
have
yet
to
see
anyone
make
an
A
on
it,
because
quality
is
an
iterative
process
or
continuing
to
grow,
but
that
assessment
will
give
you
a
benchmark
number.
It's
it's
free,
no
one's
going
to
email,
you
it's
free,
but
it's
an
opportunity
to
say:
listen,
we're
scoring
50%
or
were
scoring
60%,
and
this
is
a
number
that
we
can
work
on
as
we
continuously
prove.
So.
A
A
Well,
Istanbul
is
very
popular.
That's
what
we
usually
use
for
code
coverage
Istanbul
also
has
a
module
for
cold
coverage
from
the
front
end
that
you
can
link
in
now.
With
with
your
front
end,
automated
tests
and
I
forgot
to
mention
the
code
that
I
was
showing
you
is
all
in
github
and
I'll.
Put
that
up
and
have
it
here
as
well.
If
you'd
like
to
pull
it
down,
it
has
everything
you
need
to
get
started
with.
Writing
your
first
automated
test.
A
Yeah
I
think
it's
all
part
of
the
movement
of
continuous
improvement.
The
question
was:
is
there
a
development
strategy
if
you're
not
going
to
use
identifiers,
Zoar,
IDs,
I,
think
if
developers
and
more
developers
and
the
person
in
the
function
of
QA,
even
if
that's
a
developer,
the
more
that
they
work
together
to
find
a
solution,
the
better
it
is
for
the
whole
automation
process.
I've
had
some
people
say
we
don't
use
IDs,
we
use
attributes
and
our
attribute
says
test
in
it
and
we
and
anything
we
need
to
test.