►
From YouTube: Test-Driven Development
Description
Fkfifififififif
A
Joe
joe
we're
close
to
a
revolution
here,
martin,
I
love
the
terminology.
You
use,
it's
totally
awesome.
Okay,
so
you
talk
to
us
about
test
driven
development.
Please
explain
that
so
test
driven
development.
We
ported
it
from
software
to
hardware
and
here's
what
we
mean
by
it
in
hardware,
so
we
call
it
test
driven
manufacturing.
A
We
start
with
a
test
fixture
before
we
build
anything.
So
we
start
with
a
user
story
as
joe.
I
can
drive
a
car
that
gets
100
miles
per
gallon
so
that
I
can
improve
the
environment
of
the
world.
I
live
in,
so
that's
now
we
have
a
goal
to
hit.
Now
we
need
to
make
a
test
to
know
if
we
pass
that
goal
or
not.
So
we
get
a
set
of
dyno
rollers
and
an
emissions
collector
and
a
fuel
flow
meter.
A
So
we
can
go
through
the
epa
sitting
highway
driving
cycle
and
know
our
fuel
economy.
We
haven't
built
a
car,
yet
we've
gotten
access
to
that
test.
Fixture
before
we
built
anything.
So
we
start
with
a
failing
test
that
way.
It
focuses
all
work
directly
on
making
the
slimmest
thing.
The
quickest
thing
that
will
pass
that
test
failing
test
yeah,
we
start
with
a
failing
test
fixture
the
ability
to
measure.
Do
we
have
a
hundred
mile
per
gallon
car,
but
we
haven't
built
a
car,
yet
we've
acquired
access
to
the
test
fixture.
A
We
built
the
test
fixture
and
it's
our
job
to
be
able
to
repeat
that
test
as
cheaply
in
terms
of
time
and
money
as
possible.
So
we
can
run
that
test
hundreds
of
times
during
our
development
cycle
to
know
if
we
passed
it
yet
know
if
we're
improving,
so
it
gives
us
laser
focus
on
the
end
goal
and
it
avoids
gold
plating
or
building
more
than
we
need.
A
So
we
start
with
the
failing
test.
Now
we
build
the
product
once
we've
built
the
the
module
say:
it's
an
engine
module.
We
then
unit
test
it.
So
a
test
fixture
for
an
engine
module
for
us
is
an
accelerator
pedal,
a
fuel
gauge
and
a
shifter
all
by
itself.
So
outside
of
a
car,
you
plug
it
into
the
engine
module
sitting
on
a
test
fixture
and
you
accelerate
it
and
you
shift
its
gear
and
you
monitor
its
fuel
level.
Consumption,
you
haven't
even
put
in
a
car,
yet
so
that's
unit
testing.
A
Then
we
do
integration
testing,
we
put
it
in
the
car
and
we
verify
it
still
works
in
the
car.
Then
we
do
regression
testing,
which
is
we
run
every
test
we've
ever
built
on
the
car.
Again
we
make
sure
that
the
headlights
still
work.
It
still
turns
the
brakes
still
work.
The
horn
still
honks
so
that
that
new
module
we
introduced
didn't
just
regress
anything.
It
didn't
just
break
anything.
So
those
are
our
three
levels
of
testing
so
test
driven
development
gives
us
focus
and
it
helps
laser
focus.
A
The
team
on
just
passing
the
test,
which
is
your
valuable
thing
and
then
unit
testing
determines
did
that
is
that
module
successful
and
then
we
have
integration
testing.
Does
it
work
as
part
of
this
larger
structure,
and
then
we
have
integration,
regression,
testing,
which
is
does
introducing
that
new
work
move
us
backwards
anywhere
else,
and
if
so,
we
then
get
to
kill
work
early.
It
also
helps
us
identify
any
work,
that's
not
being
done
to
pass
a
test,
so
it
helps
identify
work.
A
That's
not
actually
adding
value
to
the
project
to
help
redirect
and
coach
those
people
to
be
excited
about
something
that
will
work
on
passing
a
test.
So
it's
easy
to
say:
hey
that
thing
you're
doing
which
test
is
that
trying
to
pass
and
help
direct
that
work
into
something?
That's
going
to
have
dramatic
value
for
us
soon
and
with
by,
and
we
know
exactly
when
it's
worked
or
not,
there's
no
guesswork
because
we
have
a
test
fixture
and
that
drives
morale.
A
That's
what
helps
cement
the
reality
of
regular
successes,
because
you
have
these
test
fixtures
that
don't
have
any
question
about
whether
you've
just
made
real
forward
progress
or
not.
And
how
do
you
test
for
things
that
are
not
immediately
visible,
such
as
longevity
of
parts?
You
would
have
accelerated
stress,
testing.
A
So
longevity
of
parts,
you'd
have
accelerated,
stress,
testing
or
you'd,
make
the
part
in
miniature
so
that
the
failure
would
happen
in
order
of
magnitude
faster,
but
in
my
world
I'll
think
about
the
things
that
we
would
care
about.
The
longevity
of
we
do
finite
element
analysis,
and
so
it's
a
simulated
structural
fail.
So
you
say:
here's
the
finite
element,
analysis
of
applying
this
force
over
these
vectors
over
this
many
repetitions.
A
Now
we
need
to
write
now
we
need
to
develop
something
in
cad
that
passes
those
tests,
those
tests
without
having
decreased
structural
properties,
so
we
create
that
test.
First,
does
fea
typically
yield
the
correct
results
or
how
useful
has
fa
turned
out
to
be?
It
completely
depends
on
the
program.
There
are
programs
such
as
ls
dyna,
that
have
achieved
complete
correlation
with
physical
crash
test
results,
for
example
in
crash
testing.
A
What
they
do
is
they
take
a
coupon
of
a
material
and
they
crush
it
in
slow
motion,
and
then
they
run
the
same
test
on
a
coupon
in
finite
element,
analysis
and
verify
they
deform
exactly
the
same
way
and
once
they
build
up
a
battery
of
different
materials,
they
have
high
correlation
between
the
two
ls
dyna
has
done
that
for
things
like
entire
cars
at
a
time,
it's
very
refined.
Now
it's
an
expensive
piece
of
software,
but
there's
a
free
30-day
trial.
A
A
So
there
are
some
types
of
problems
like
maybe
a
piece
of
fea
software
has
high
correlation
with
tubes
that
are
aluminum
or
certain
grades
of
steel,
but
has
no
correlation
of
carbon
composite
tubes
or
square
shapes,
and
so
it
helps
to
understand
what
the
finite
element
element
analysis.
Software
is
built
to
do
to
make
sure
you're
using
it
for
something
it
has
high
correlation
on
okay,
excellent.
This
is
test
driven
development.