►
From YouTube: DevOps For ASP.NET Developers Pt.5 - Unit Testing
Description
Software testing is an essential practice for producing high quality, production ready software. It helps improve the stability, maintainability, and the confidence that developers have in their code.
In part 5 of our DevOps For ASP.NET Developers series, Abel and Jeremy discuss the benefits of software testing and some of the various ways we can approach testing. They show us how to get started writing tests in .NET Core and also how to run them in our Azure Devops pipeline.
[01:20] - Benefits of unit testing
[07:26] - Different ways of writing tests
[12:08] - Unit testing vs Integration testing
[15:48] - Running tests in Azure DevOps
[24:42] - How long do tests run for?
A
Everyone
donovan
brown
here
welcome
to
the
devops
for
asp.net
developer
series.
In
this
episode,
we're
going
to
focus
on
unit
testing
unit
testing
is
critical
to
delivering
high
quality
code
using
Azure
pipelines.
You
can
run
any
unit
testing
framework
during
your
build.
The
results
of
the
build
can
be
shown
on
your
build
summary
and
on
team
dashboards.
Let's
see
how
Abel
and
Jeremy
add
unit
testing
to
their
project.
B
C
B
A
C
You
did
test,
but
the
theory
behind
unit
testing
is
every
line
of
code
that
you
write.
That
does
things
you
should
also
have
other
lines
of
code
that
test
it
to
make
sure
it
does
what
it's
supposed
to
do.
Okay,
right
so
think
of,
like
a
calculator
function
like
an
ad
function,
you
pass
in
two
variables
and
you
add
them
together
and
you
return
back
in
value
right
right
that
function
right.
C
C
It
is
more
work
and
you
know
when
I
first
looked
at
this,
my
first
thought
was
great
now
you're
asking
me
to
write
double
the
amount
of
code
right
first
I
have
to
write
the
implementation
then
write
the
tests
that
test
it,
and
the
answer
is
yes,
although
it's
not
quite
double
I
would
say
it's
about
a
third
amount
of
time
that
you
take
to
implement
that
about
how
long
right
right
unit
tests
but
they're
super
super
valuable
and
here's
the
thing.
When
you
first
write
unit
tests,
it
seems
really
silly.
C
Why
am
I
doing
this?
Why
do
I
even
care?
How
is
this
even
helping
me
maintain
quality
right
right?
The
important
thing
to
remember,
though,
is
for
us
developers
fixing
bugs
is
not
hard
if
we
can
reproduce
the
bug.
If
we
know
the
bug
is
there,
then
it's
really
not
that
hard
to
set
a
breakpoint
game
over
right.
You
just
go
and
there
figure
out
what's
wrong
and
fix
it
sure.
C
A
C
Way
it
is,
but
the
problem
is
a
lot
of
times,
think
about
when
we're
writing
code,
not
when
we
first
start
out
the
project
and
it's
tiny,
but
it's
been
running
for
a
while
right
and
somebody
asks
us
to
add
some
functionality.
So
we
go
in
there.
We
add
the
functionality
right
for
that,
we're
awesome
and
then
we
broke
the
app
in
four
different
places
right.
A
C
Right
right,
so
the
that's
really
where
unit
testing
comes
in
right,
because
if
I
have
unit
test
for
all
of
my
code
that
tests
how
my
code
should
behave
and
I
go
in
there,
an
adding
new
functionality
or
I
fix
a
bug
or
something
like
that.
I
can
add
that
new
functionality
I
can
break
the
app
somewhere
down
the
line.
But
my
unit
test
will
catch
that
right,
so
immediately,
I
can
find
it
fix.
It
set
a
breakpoint
whatever
do
whatever
I
need
to
and
I
can
quickly
fix
it.
B
A
A
B
A
B
C
B
C
100%,
true
right,
so
in
order
to
be
able
to
write
unit
tests,
your
code
needs
to
be
testable
right.
You
have
to
write
your
code
in
such
a
way
that
it's
testable,
like
you
said,
if
you
just
have
some
big
giant
monolithic,
spaghetti
code,
that's
all
intertwine
to
get.
How
are
you
gonna
test
that
that's
impossible
right?
There's,
no
way
that
you
could
possibly
do
that
so
when
I
first
started
writing
unit
tests
well,
my
first
reaction
was
at
this.
This
is
way
too
long.
B
C
I
didn't
really
see
the
value
until
I
really
started
using
it,
but
once
I
started
writing
my
tests.
I
realized
that
I
now
need
to
write
my
code
in
such
a
fashion
that
it's
testable,
so
that
did
two
things
number
one.
It
changed
the
way
that
I
wrote
my
code
and
number
two.
Consequently,
my
code
was
became
much
better
quality
because
it's
written
in
a
testable
fashion,
so
it's
no
longer
spaghetti
together.
So.
B
So
that
actually
is
interesting
too
because
it
feels
like
it
could
go
almost
back
to
the
design
and
the
specification
piece
of
this
too,
because
when
I
think
about
writing
tests,
there's
there's
two
approaches:
those
you
write
a
piece
of
code
and
you
could
test
it
yeah
or
maybe
you
get
a
story
on
your
backlog,
yeah
and
you
write
a
test
for
that
story
and
you
make
sure
the
code
does
that.
Yes,
if
someone
tries
to
come
to
you
and
say
this
function,
should
return
quickly.
B
C
B
C
To
speak
right,
right,
right,
absolutely
and
and
I'm
glad
you
brought
that
up
because
there's
like
you
said
there
aren't,
there
are
a
couple
different
ways
to
write
your
unit
tests
when
I
first
started
writing
unit
tests.
It
was
basically
every
method
that
I
had
I
would
write
a
unit
test
for
us.
So
as
I
wrote,
the
method
I
would
quickly
write
a
unit
test
that
would
test
that
specific
method,
but
that
kind
of
requires
a
lot
of
knowledge
of
what
that
method
is
going
to
do,
and
it's
it
there's
nothing
wrong
with
it.
C
There's
this
it's
a
perfectly
OK
way
to
write
your
unit
test,
but
then
I
ran
into
a
friend
of
mine
who
showed
me
how
to
do
behavioral,
driven
development,
so
at
first
I
was
doing
test-driven
development
right
now
go
about
your
tests
first
and
then
you
write,
you
write
your
methods,
but
my
biggest
problem
when
I
was
doing
just
straight.
Tdd
was
as
I
was
writing
my
tests.
I
was
like
I
have
no
idea
how
to
even
begin
to
write
my
test.
C
Cuz
I,
don't
even
know
what
the
methods
gonna
do
so
then
I
would
kind
of
go
into
the
method
and
kind
of
jump
back
and
forth,
and
that
worked
ok
but
I
like
the
whole.
This
idea
of
BDD
the
behavioral
driven
development,
where
you
describe
the
behaviors
and
it's
pretty
much
exactly
what
you
said
here.
We
have
a
user
story
and
for
this
particular
user
story,
these
are
all
the
behaviors
that
I
want
to
happen
right
now,
whether.
A
C
Needs
to
return
back
within
two
seconds,
or
maybe
it's
you
know.
When
the
user
clicks
on
the
upload
button,
it's
gonna,
it's
gonna,
take
that
data
and
put
it
into
the
database
and
in
these
tables
or
whatever
right
so
I
mean
using
behavioral
driven
development
number
one.
Your
test
becomes
super
readable
and
the
other
thing
is
Wow.
It's
to
me,
it's
easier
conceptually
to
figure
out.
Ok,
these
are
the
tests
that
I
need
to
write
and
I.
Do
like
the
readability
factor
and
I'll
show
you
that
in
a
little
bit.
B
Well,
it
sounds
like
some
some
tests
because
obviously
I
haven't
been
testing
properly,
but
I
have
come
across
tests
in
the
Haley,
and
you
see
this
format
of
given
something
when
something
happens
then
expect
a
result.
No
results,
so
I've
heard
of
two
different
ways
to
approach:
there's
a
range
act
and
which
feels
like
implementation,
detail
of
the
tests
and
there's
given
when
then,
which
sounds
like
the
expected
behavior
right
of
the
test
right.
C
B
C
Yes,
so
so
you
can
think
of
tests
as
at
this
point
in
time.
This
is
this
is
how
my
code
is
behavior.
This
is
how
my
code
should
behave
like
herd
should
pass
all
of
those
types
of
tests,
so
if
I
need
to
go
in
and
add
functionality
or
fix
a
bug,
we're
always
afraid
that
we're
gonna
like
mess
something
up
right
and
the
test
gives
us
that
peace
of
mind
that,
even
though
I
made
these
changes,
the
rest
of
the
behavior
still
is
the
same.
C
I
think
one
of
the
best
examples
that
I
can
think
of
in
my
career
I
was
given
it's
just
quite
a
few
years
ago,
but
I
was
on
a
project
and
I
wrote
this
data
layer.
This
was
this
was
before
enemy
framework
and
all
that
nonsense.
I
wrote
a
data
layer
at
that
connected
up
to
sequel,
server,
right
and
I,
embedded
a
bunch
of
sequel
and
all
that
nonsense.
I
wrote
it
really
badly,
but
anyway,
that's
that's.
C
C
I
can
do
that,
but
luckily
I
broke
very,
very
extensive
unit
tests
so
because
of
that
I
just
went
in
there
toward
the
code
apart,
you
ripped
it
into
pieces,
rewrote
everything
when
my
unit
tests
and
immediately
like
five
of
my
tests
broke
on
my
career
for
that
it
broke,
let
me
go
and
fix
it
and
then
eventually,
I'll
become
trading
turned
green
and
I
was
like.
Oh,
let's
see
if
this
really
works
and
bam,
it
just
worked
right.
C
B
Before
we
look
at
how
we
scale
this,
because
obviously
everyone
running
unit
tests
on
their
laptop
is
one
thing.
But
how
do
you
really
know?
Yeah
people
have
taken
that
that
step,
I
understand,
there's
a
difference
between
unit
tests
and
things
like
integration
tests
right,
for
example.
So
how
would
I
test
something
that
interacts
with
a
database
layer
if
I
don't
know
that
there's
going
to
be
a
database
available
for.
C
Example,
that
is
a
fantastic
question,
so
the
idea
of
unit
test
is
you
want
to
test.
You
only
want
to
test
one
unit
of
work,
so
if
my
unit
of
work
includes
hitting
the
database
getting
data,
bringing
that
data
back
and
then
manipulating
in
some
way
right,
that's
that
seems
pretty
common
sure.
My
test
should
test
the
logic
of
manipulating
that
data.
It
shouldn't
test.
The
logic
of
is
my
database.
Query,
correct,
right,
I'm,
gonna,
assume,
that's
correct!
That's
not
the
important
part.
The
important
part
is,
is
my
logic
right
now.
C
The
reason
why
I
want
just
that
one
unit
of
work
is
because,
when
this
test
fails
now
I'll
know
exactly
where
the
test
failed.
Did
it
fail
in
the
database
query
or
did
it
fail
in
my
logic?
Well,
I
know
it
failed
in
my
logic
and
not
the
database
query
because
I'm
not
testing
that
right.
So
that's
one!
So
that's
the
theory
behind
you
want
to
test
one
unit
of
work.
The
other
thing,
though,
is
when
you're
testing,
for
instance,
and
you
have
an
outside
dependency
like
a
database.
C
How
are
you
supposed
to
test
that
right?
Back
in
my
day
when
we
first
started
doing
this,
we
would
have
a
special
test
database,
all
right
special
data,
known
set
of
data
right
sure.
So
then,
before
you
ran
the
test,
you
need
to
make
sure
the
data
was
in
the
right
state.
Then
you
would
run
the
test
and
then,
with
the
known
set
of
data,
they
would
return
back
in
own
sort
of
data.
C
Would
take
for
freaking
ever
right
when
you
make
a
call
to
the
database
or
make
a
call
to
a
web
service
number
one.
You
have
to
have
the
database
out
there
or
the
web
service
out
there
or
the
API
sitting
in
something
all
right.
You
would
have
you
have
to
have
the
stuff
there
for
you
to
actually
test
these
outside
systems.
C
C
Right
or
is
it
my
logic
is
so
we
can
have
broken
tests,
read
tests
and
no
clue.
Is
it
really
the
logic
that's
broken
or
the
whole
setup
that's
broken
and
to
make
matters
worse?
What
happens
if
you
have
more
than
one
person
trying
to
run
these
tests
at
the
same
time,
you
can
start
walking
on
top
of
each
other's
data.
Then
it
turns
into
a
giant
cluster
sure.
So
to
mitigate
all
of
that,
you
you.
C
We
want
to
do
something
called
mocking
right
where,
instead
of
making
a
call
to
the
database,
now
I'm
going
to
make
a
fake
call
to
the
database
where
I
don't
really
go
to
the
database,
but
I'll
just
return
back
unknown.
My
known
set
of
data.
So
this
way
I
don't
even
have
to
have
that
database
out
there
I
don't
even
have
to
have
anything
deployed.
I
don't
have
to
have
my
web
service.
It
is
my
API
layer
or
anything
right,
because
I'm
gonna
mock
those
calls
out.
C
So
if
the
call
is
to
return
me,
the
top
ten
most
frequented
items
in
my
catalog
instead
of
hitting
a
real
database
I'll,
just
be
like.
Okay,
this
is
the
method
than
the
caller,
or
this
is
the
sequel
method
I'm
going
to
call-
and
this
is
the
I'll
just
say
we
turn
back
this
specific
data
and
I'll
show
you
some
examples
of
mocking
as
well,
but
mocking
is
a
extremely
important
right
any
outside
dependencies.
You
want
to
be
able
to
mock.
B
Good
terrible
joke
people
call
that
dad
humor,
but
let's
talk
about
the
fact
that
I'm
sold
now
on
unit
tests
that
IV
can
build
them
and
run
them
here.
But
there's
a
component
measure
DevOps
that
also
recognize
and
integrates
absolutely.
C
So,
as
your
DevOps
it
you
can
do
whatever
types
of
unit
tests
you
want
right,
so
you
can
write
unit
tests
using
MS
test.
You
can
write
unit
tests
using
X
unit
and
unit,
there's
all
sorts
of
different
types
of
unit
testing
frameworks
and,
as
you
develop
supports
them
all.
So
why
don't
I
jump
in
and
kind
of
show
you
how
you
can
set
all
this
sounds
great
all
right.
So
on
my
screen
right
now,
I
have
a
some
some
code
for
our
hotel,
360
app,
and
this
one
here
is
the
controller
for
the
testimonials.
C
B
C
What
it
does
is,
it
hits
my
testimonial
service
and
it
calls
the
get
testimonial
method.
Ok,
right,
what's
kind
of
cool
is
whoever
wrote
this
code?
They
must
have
thought
about.
Let's
make
this
code
testable
good
job,
even
though
you
didn't
write
the
test,
he
made
your
code
testable
right
right,
so
what
they
did
was
they
created
an
interface.
You
know
I
customer
testimonial
interface,
and
if
we
look
at
this
particular
interface,
it's
pretty
simple.
It
just
says:
I
have
one
method
that
says
get
just
testimonial
right.
C
B
C
To
go
so
when
I
write
my
test
easy
enough
to
create
a
test
project:
let's
go
ahead,
you
just
right
click,
it
and
say
add
a
new
project
and
immediately
you'll,
see
in
the
wizard
it'll.
Ask
you
ok,
what
type
of
projects
do
you
want
to
create
and,
of
course,
I'm
initializing
everything
one
of
the
things
that
it's
going
to
is
going
to
have
is
different
types
of
testing
projects
that
you
can
use.
C
C
Do
about
the
same
stuff,
there's
a
little
bit
of
differences
here
and
there,
but
at
the
end
the
day
is
it's
a
unit
test
right?
Okay,
so
pick
the
unit
testing
framework
that
makes
sense
for
you
and
your
team.
So
if
I
look
at
my
test,
my
test
is
pretty
simple.
My
idea
is,
if
I
browse
through
the
testament
testimonial
API,
let's
go
ahead
and
return
all
the
testimonials
in
a
JSON
format.
So
if
you
look
at
my
index,
that's
exactly
what
it
does
right.
B
C
C
C
C
B
C
Yeah,
the
mocking
framework
with
fakes
is
freaking,
amazing
right
because,
ultimately,
no
matter
what
mocking
framework
you
use.
What
do
you
end
up
with?
You
have
an
interface
you
implement
that
particular
interface
with
the
mock
and
and
then
you
just
fill
out
the
method
that
you
want
and
return
back
whatever
data
you
alright,
but
you
have
to
have
interfaces,
which
means
you
have
to
go
back
in
refactor
your
code
to
use
interfaces
like
our
code
right
now.
It's
already
refactoring
in
a
way
that
we're
using
interfaces
what's
powerful
about
Microsoft
fakes.
You
don't
need
interfaces.
C
You
can
literally
mock
out
any
object,
any
method,
public
private
static
system.
It
doesn't
matter
right.
So
it's
super
powerful
and
super
useful.
Like
I
said
I,
don't
know
if
you
can
use
it
with
net
core.
Yet
I
should
have
looked
that
up
before
we
started,
but
it's
a
cool
marking
program,
but
anyway,
I
used
moq,
so
I
created
my
mock
and
when
they
call
get
testimony,
oh
I'm
just
going
to
return
my
customer
testimonial.
Ok!
So
then
I
instantiate,
my
controller
right
here
and
I
pass
in
my
mock.
Okay.
B
B
C
So,
in
this
case
here
my
act
is
I'm
gonna
call
my
index
and
I'm
gonna
get
a
JSON
result
back
and
now
I'm
gonna
a
couple
things
I'm
gonna
do
the
first
thing
I
thought
I
want
to
do
is
I
want
to
make
sure
that
the
get
testimonial
call
this
method,
testimonial
service
guests,
get
testimonial
I
want
to
make
sure
it
actually
got
called
right,
so
I'm
checking
did
it
ever
get
called.
Did
it
get
called
one
time
because
I
only
want
it
to
be
called
one
time?
C
So
that's
what
my
first
dessert
is
doing,
and
then
my
second
assert
is
I
want
to
make
sure
that
it's
going
to
return
back.
The
correct
data,
which
is
the
fake
customer
testimonial,
makes
sense
right
so
that
right
there
is
how
you
can
write
a
particular
unit
test
right.
So
now,
I
can
check
all
this
code
in,
but
during
my
build,
I
want
to
make
sure
we
compile
all
these
unit
tests
and
run
these
unit
tests.
C
Okay,
so
the
way
that
we
would
end
up
doing,
that
is,
let's
go
ahead
and
jump
back
into
our
pipeline
here.
Is
our
pipeline
build
alright?
So
this
is
a
pretty
standard
for
a
dotnet
core
application.
The
first
thing
that
I
do
I
scan
my
source
code
using
what
source
bolt
for
security
violations
or
flaws,
or
things
like
that
then
I'm
going
to
use
net
core
SDK
to
okay.
B
C
Yep
yep
and
then
after
I
do
a
restore
I
literally
just
call
it
and
that's
gonna
build
my
app
as
well.
I'm,
literally
just
gonna
call
net
test,
okay
right.
So
if
you
do
everything
through
the
command
line,
actually
I'd
have
this
screen
right
here,
ready
to
go
right.
So,
if
you're
doing
everything
through
the
command
line,
you
can
just
say
net
test
and
that
will
go
ahead
and
build
all
of
your
tests
and
run
all
of
your
tests
right.
C
B
C
C
That's
really
all
the
magic.
That's
there,
I
run
a
dotnet
test,
make
sure
that
I
get
the
TRX
file
and
then
let's
go
ahead
and
publish
it.
Okay,
I'm
the
publish
task.
So
once
we
do
that,
we
end
up
with
a
build:
let's
go
ahead
and
look
at
one
of
our
builds
and
see
what
the
build
report
looks
like
we'll
go
ahead
and
jump
in
here.
Let's
go
into
our
build
summary
and
you
can
see.
C
So
you
can
run
these
tests
in
parallel
as
well
right
right,
so
that
can
really
speeds
things
up,
especially
if
you
have
a
really
beefy
build
engine.
That
has
a
lot
of
course
right.
Then
you
can
just
run
everything
in
parallel.
It
goes
super
fast.
So
here's
the
interesting
thing
about
how
long
do
test
run
unit
tests
are
so
important,
especially
in
today's
DevOps
II
world,
where
we're
continuously
pushing
code
out
into
production
right.
So
back
in
my
day,
how
did
we
super
old?
How
did
we
find
our
bunks
right?
C
C
So
I'm,
like
I'm,
awesome,
I
just
closed
out
all
these
user
stories,
although
I
might
have
written
a
whole
bunch
of
bugs
I'm,
not
gonna,
know
that
until
QA
finally
finds
it
right
and
when
they
do
I'll
go
and
fix
it
right
or
maybe
I'm
off
to
another
project
in
some
other
poor
fool
has
to
fix.
Memorize.
C
Problem
with
that
approach
is
for
QA
to
find
it,
they
have
to
run
functional
tests
and
they
have
to
run
end-to-end
functional
tests
to
find
any
of
the
problems.
If
it's
buried
way
down
deep
right
and
then
functional
testing,
how
long
does
that
take
a
long
time
for
freaking
ever
right
easily?
You
can
do
end
in
functional
testing
for
two
weeks
easily.
You
can
do
end-to-end
functional
testing
for
three
months
and.
C
C
C
Course,
of
course,
right:
that's
the
we
don't
write
bugs,
but
so
in
a
DevOps
world,
where
were
let's
say
our
sprints
two
weeks
long
and
we're
pushing
in
a
production
every
two
weeks?
How
are
we
going
to
maintain
quality
if
our
testing
and
to
end
functional
testing
takes
three
weeks
to
do
so?
Every
change
that
I
have
to
do
requires
the
QA
to
do
the
whole
and
in
testing
again.
How
are
they
going
to
keep
up
right?
They
can
right.
So
how
do
we
maintain
quality
in
this
DevOps
world?
C
Where
we
still
can
push
code
out
really
quickly
and
the
answer?
Is
we
moved
well
if
you
look
at
what
we've
done
with
Azure
DevOps,
so
it
the
azure
devops
product
is
so
that
that
team
we
used
to
do
end-to-end,
functional
testing
and
it
would
take
close
to
six
monster
to
do
full
and
end
testing,
so
we're
shipping
new
code
every
three
weeks
so
clearly
something.
C
We
started
moving
away
from
functional
testing.
Our
first
thought
was:
let's
do
automated
UI
testing
mm-hmm,
so
we
took
all
our
functional
testing.
We
spent
a
gajillion
dollars
to
have
people
write
automated
UI
tests
and
they
did
and
then
we
would
run
them
and
two
things
happen,
number
one.
It
would
took
forever
to
run
because
automated
UI
testing.
C
C
B
C
C
Eventually,
we
just
started
ignoring
this
red
tie
right
because
it's
like,
oh
sure,
it's
just
it's
just
a
fluke,
and
then
you
didn't
ignore
it,
so
they
basically
turned
useless
for
us.
So
we
moved
away
from
functional
testing,
whether
it's
by
humans
or
automated
UI,
and
then
we
moved
our
efforts
more
to
the
dev
side
right.
We
shifted
left
so
now
we're
gonna
try
to
test
everything
using
unit
tests
very,
very
detailed,
very,
very
careful
unit
testing,
every
single
pull
request
that
we
do
have
to
pass
our
tier
1
into
or
2
unit
test.
C
C
This
is
my
engineering
dashboard
for
Azure
DevOps.
Of
course,
it's
rendering
right
now.
I
need
to
find
my
pole
request
here.
We
go
and
we'll
go
ahead
and
jump
into
this
live
and
we'll
see
a
pull
request.
That's
actually
going
on.
Let's
go
ahead
and
just
grab
any
one
of
these.
Let's
grab
a
green
line,
so
here's
a
build
right.
You
do
a
pull
request.
It
kicks
off
the
build
completely
automated
yep.
If
you
look
at
our
summary
and
you
look
at
our
testing
Wow.
C
How
do
we
maintain
quality
at
a
pace
where
we're
pushing
code
into
production
once
every
three
weeks
and
what
we
don't
usually
tell
people,
but
I
guess
I'll,
just
tell
the
world
down,
we
push
bug,
fixes
multiple
times
every
single
day.
So
how
do
you
maintain
quality
when
you're
moving
at
that
pace?
The
answer
is:
every
single
developer.
Check-In
has
to
pass
74,000
unit
tests.
C
B
C
And
that's
exactly
what
we're
doing
with
the
azure
dev
ops
team
as
well.
If
my
pull
requests,
if
the
build
breaks
that
code-
nobody
even
reviews
it,
it
just
automatically
gets
rejected.
Your
your
build
needs
to
succeed,
but
our
build
is
not
just.
It
needs
to
compile,
which
is,
of
course
super
important,
but
it
needs
to
pass
all
75,000.
B
C
It's
not
it's
still
important.
You
still
need
eyeballs
on
the
product.
You
still.
You
still
need
to
do
some
quick
testing
of
the
UI
itself,
whether
it's
automated
or
human,
or
whatever
mean
you
still
need
that.
But
the
big
bulk
of
your
testing
effort
needs
to
be
on
the
developers
to
write
good
unit
tests
and
not
just
bogus
tests
right
I
can
write
a
hundred
tests.
That
gives
me
100%
code
coverage
that
doesn't
a
sort
of
thing
right.
B
C
B
Actually
draws
to
mind,
the
kind
of
last
piece
of
the
puzzle
for
me
is
that,
in
a
code
base
with
well-written
tests,
I
don't
even
need
to
go
to
a
developer
wiki
to
understand
how
to
use
the
code
yeah.
The
tests
not
only
explain
what
the
codes
supposed
to
do,
but
they
demonstrate
how
to
use
the
code
and.
C
And-
and
it
that's
one
of
the
reasons
why
I
love
like
the
whole
behavioral
driven
development
right,
because
your
tests
become
so
readable
that
you're,
like
oh
I,
know
what's
going
on.
So
let
me
give
a
quick
example
of
that
as
well.
If
I
look
at
some
code,
that
I
wrote
for
Donovan
I
have
a
whole
bunch
of
tests.
Of
course,
the
font
it's
released,
tiny,
so
you'll
have
to
jump
in
here,
but
one
of
the
is
to
adjust
my
glasses
okay,.
C
I
wrote
all
these
tests
I
wanted
to
make
them
very
readable.
So
so
anybody
could
just
look
at
it
and
be
like
Oh,
for
instance,
managed
headshots
for
advocates
from
the
view
advocates.
I,
add
a
headshot
by
clicking
on
it
all
right.
So
if
I
jump
into
my
code,
that's
literally
what
it's
doing
is
just
testing
to
make
sure
that
when
I
click
the
upload
of
a
headshot
that
it
actually
does
what
it's
supposed
to
do.
If
I
look
at
my
code.
C
A
C
Route
it
to
an
error
page
and
if
they
did
well
grab
it
in
a
memory
stream
wrap
it
in
my
object,
then
push
it
into
my
repository
nice.
So
then,
my
unit
test
needs
to
test
this
right.
It
needs
to
test
that
logic.
So
that's
that's
what
it
does,
but
now
my
tests
become
very,
very
readable
if
I
enter
an
empty
file
list.
C
Well,
make
sure
I
write
back
to
the
view
or
something
like
this
right,
so
that
kind
of
goes
back
to
your
whole
thing
of
even
if
I'm
jumping
into
a
new
project
or
I'm
jumping
into
sections
of
code
that
I
haven't
looked
at
before
I
can
look
at
these
tests
to
help
me
figure
out.
What
is
my
code
actually
doing?
I'm.