►
From YouTube: Donald Whyte - Testing in Rust
Description
A Primer in Testing and Mocking
Rust is designed for building low-level systems processes that are reliable and safe. Nevertheless, it is still important for developers to ensure their code is doing the right thing. To achieve this, Rust has a rich set of built-in testing tools for writing unit tests.
In this talk we cover general unit testing techniques for Rust. We will also demonstrate how to mock out complex dependencies using the double crate. Examples will range from simple cases to complex cases that you'll often see when testing real world systems.
The talk is suitable for both novice and experienced Rust developers, as well as non-Rust developers who are interested in learning more about the language.
Donald Whyte is a software engineer at a leading quant hedgefund. He has thorough experience in distributed systems and machine learning. Previously, he worked at Bloomberg where he built core infrastructure technology that is still used across the firm globally.
A Rust and distributed systems enthusiast, Donald has given many talks about software infrastructure and distributed systems around the world.
Rust devroom @ FOSDEM 2018
https://fosdem.org/2018/schedule/event/rust_testing_mocking/
These talks have been recorded at FOSDEM (https://fosdem.org/)
This work is licensed under the Creative Commons Attribution 2.0 Belgium Licence.
To view a copy of this licence, visit http://creativecommons.org/licenses/by/2.0/be/deed.en
A
A
So
if
we
had
some
production
code
say
in
this
Lib
de
RS
file,
here
we
have
say
add:
it's
just
adds
to
an
integer.
We
can
write
tests
for
this
function
by
defining
a
private
test,
module
in
the
same
source
file
and
annotating
it
with
CFG
tests,
which
tells
cargo
to
only
build
this
code
in
the
test
belt,
not
in
a
production
binary.
A
Then
you
write
various
test
functions
inside
and
you
annotate
in
each
individual
test
with
tests
and
then,
when
you
run
cargo
tests
it
builds
all
the
production
code
builds
the
test
code
and
actually
runs
all
of
those
test
functions.
Rust
has
a
native
support
for
documentation
tests,
so
running
tests
in
that
are
actually
example,
code
that
are
in
your
documentation
to
make
sure
your
example
code
and
your
your
library
don't
actually
miss
a
line
as
well
as
integration
tests.
But
again
the
focus
here
is
on
unit
tests
and
walking.
A
So
the
motivation
behind
mocking
is
that
if
you
imagine
any
software
system,
you
know
it's
basically
a
dag
of
various
components
and
if
we
wanted
to
test
one
of
these
components,
you
know
we
have
many
many
dependencies
or
may
have
many
dependencies
in
this
case
at
this
top
level
component,
as
highlighted
in
red.
If
we
were
to
test
this,
we
have
to
actually
construct
instantiate
and
configure
all
three
of
their
dependencies
and
then
their
dependencies
as
well.
A
A
We
typically
eliminate
anything:
that's
non-deterministic
that
can't
be
reliably
controlled
in
a
unit
test,
datasources
network
connections,
potentially
libraries
that
have
global
state
or
something
some
horrible
library
the
end
of
using,
and
you
can
also
eliminate
large
internal
dependencies
as
well.
There's
advantages
and
disadvantages
to
doing
that.
But
if
you've
got
particularly
large
complex
of
dependencies
that
take
a
long
time
to
set
up,
you
can
eliminate
those
as
well.
So
the
solution
to
this
to
use
the
test
double
and
that
kind
of
comes
from
the
notion
of
a
stunt
double
in
films
and
I'm
surprised.
A
A
In
this
case,
what
we're
actually
covering
is
spies,
which
is
a
specific
type
that
you
can
configure
to
behave
in
different
ways,
but
it
also
records
all
the
interaction
of
the
code
and
the
test
has
with
it
all
the
times
it
was
called
and
what
it
was
called
with,
and
what
this
is
called
as
behavior,
which
is
a
style
of
unit
testing,
is
a
style
of
writing
tests
by
testing
the
code
by
asserting
on
its
interaction
with
his
collaborators
or
its
dependencies.
So
immersed,
we
can
generate
testable
x'
in
a
variety
of
ways.
A
This
has
one
method,
profit
act
which
takes
some
time
stamp
and
then
we'll
return
the
profit
at
that,
given
time
stamp,
we
have
a
function
called
predicts
profit
over
time
whose
goal
is
to
generate
a
time
series
of
profits.
So
we
give
it
a
start
and
end
time,
series
the
model
itself
which
can
be
any
model,
and
then
we
simply
iterate
through
that
through
all
of
the
individual
time
stamps
generating
the
profit
of
that
time
stamp
and
then
returning
a
vector
of
the
profits,
and
we
want
to
test
this
function,
simple
function
but
illustration
purposes.
A
Let's
test
it
so
recall
that
our
test
should
be
repeatable
and
not
rely
in
an
external
environment.
However,
this
is
very
challenging
in
this
case,
because
the
profit
model
is
a
very
complex
beast.
Predicting
profit
is
really
hard,
so
real
implementations
actually
use
a
lot
of
different
data
sources,
a
lot
of
very
complex
mathematical
models.
A
So
if
you
just
want
to
test
this
simple
basic
code
here,
you
probably
don't
want
to
have
this
ginormous
setup
of
what
is
extremely
complex
for
piyah
tree
code,
so
we
mock
it
and
in
R
us
we
do
this
with
two
macros.
The
first
is
mocked
rate,
so
much
rate
generates
a
struct
that
has
a
bunch
of
boilerplate
and
bookkeeping
inside
it
to
keep
track
of
what
how
it's
been
called
and
how
it
hasn't.
So,
in
this
case,
we
have
this
trait.
We
call
mock
trait.
A
This
is
the
name
of
our
mock
struct,
and
then
we
list
the
methods
in
the
trait
that
we're
mocking.
So
it
generates
the
right
boilerplate
code
internally,
then
we
have
to
explicitly
tell
the
risk
compiler
to
that.
The
mock
model
implements
the
profit
model
trait,
so
we
have
import
profit
model
for
mock,
and
then
we
have
the
mock
method
macro
inside
it,
which
again
will
generate
the
actual
real
profit
at
function
which
caused
our
internal
struct,
and
so
that's
the
kind
of
light.
A
That's
all
the
code
you
need
to
generate
in
what
that
has
all
the
features
that
I'm
about
to
explain.
So
actually
using
this,
if
you
imagine
you
wanted
to
just
say
one
through
three
timestamps
and
assert
that
the
profit
over
time,
the
time
series
and
generated
was
correct
and
at
the
profit
model
was
used
in
the
correct
manner.
We
instantiate
the
mock
by
doing
mock
model
default,
which
just
creates
a
default
initialized
mock
model.
We
say
profit
that
return
value
ten
and
then
this
thing
will
the
profit
foot
method
will
just
keep
returning
Tet.
A
So
we
see
that
the
actual
time
series
it
returns
is
ten
ten
ten
and
we
can
make
assertions
at
the
end
of
the
test
how
the
mock
was
caught.
So
in
this
case,
profit
at
non
cause
is
three
and
there's
various
ways
you
can
set
mock
behavior.
If
you
don't
specify
anything,
it
just
uses
a
default
value
of
the
return
type.
We
can
set
a
single
return
value
for
all
calls
like
we
did
before.
We
can
set
sequence
of
return
values,
so
1
5
10.
A
We
can
set
return
values
for
specific
arguments,
so
we
can
say
for
timestamp,
1
return
this
otherwise
do
some
other
default
behavior
in
this
case
return
0
and
we
can
even
use
arbitrary
functions
as
well
or
closures,
and
the
benefit
of
doing
it
like
this,
as
opposed
to
just
writing
a
mock
implementation
that
has
that
code
in
like
manually
confirm
writing
a
markup
limitation.
Is
that
in
this
way
you
get
all
the
boilerplate
and
code
generated.
A
So
you
can
do
these
types
of
assertions
that
about
to
discuss
so
once
you've
configured
the
mock
and
how
it's
supposed
to
behave.
You
want
to
assert
that
it
was
used
as
expected.
It
was
called
the
right
number
of
times
and
had
the
right
arguments
now,
there's
fairly
loose
assertions,
so
you
can
say
the
mock
was
called
at
least
once
it
was
called
with
one
and
it
all.
It
was
called
with
time
someone
and
also
timestamp
0.
Well
often,
you
actually
want
to
tighten
your
call
assertion,
so
you
might
want
to
say.
A
Not
only
do
you
care
that
it
was
called
with
1
and
0,
but
you
also
care
that
it
never
had
any
more
calls
than
that.
So
has
caused
exactly
1
0
2,
which
is
well
past
because
in
this
case
we're
passing
timestamp
0
to
2
inclusive
and
then
you
can
even
say
has
caused
exactly
in
order
and
it's
kind
of
up
to
you
how
tight
you
want
to
make
your
assertions
or
loose
and
that's
something
to
discuss
in
a
second.
A
We
can
also
mock
free
functions.
So,
for
example,
if
you're
passing
in
some
function
a
box
function,
for
example,
for
runtime
polymorphism,
you
can
pass
that
in
as
well.
You
can
generate
something
for
that
as
well.
Sorry,
so
here
we
have
mock
funk.
We
specify
the
actual
mock
object,
that
stores
all
the
bookkeeping,
the
actual
function
itself,
which
is
just
a
closure
and
then
the
return,
types
and
argument
types
and
whatnot,
and
then
you
can
specify
just
like
you
would
with
the
traipse
behavior.
It
will
return
ten
and
also
specify
how
it
was
used.
A
So
say
we
had
some
function
that
we
expected
to
call
it
the
the
function
we
pass
in
twice
then
we
say
that
it
was
called
two
times,
so
that's
all
well
and
good,
but
there's
some
serious
of
that
disadvantages,
mocking
if
you're,
not
careful.
So
let's
talk
about
another
use
case.
So
imagine
we
were
trying
to
test
how
a
robot
makes
decisions
so
suppose
that
we
have
some
robot
logic,
and
this
thing
takes
some
world
States.
A
So
has
some
like
perception
of
what
the
world
looks
like,
and
this
is
a
value
type,
just
a
basic
struct,
and
then
we
have
a
robot
which
takes
some
internal
state
and
then
decides
what
to
do
and
once
it's
decided
it
acts
on
those
decisions
by
correlate
by
actually
calling
this
actuator
component
here
so
saying,
I
want
to
move
forward
or
I
want
to
speak
in
this
case,
suppose
that
we
wanted
to
test
this
robot
logic.
This
is
very
complex
logic
and
it's
a
kind
of
thing
that
we
want
to
poke
and
prod.
A
So
we
want
to
mock
the
actuator
in
this
case,
because
if
this
world
state
is
just
a
simple
value
type,
we
can
just
construct
that
as
a
struct
and
just
in
and
have
various
different
unit
tests
with
various
different
world
states.
The
robot
is
the
complex,
hard
part
and
the
actuator,
if
you
imagine
that
this
robot
was
say
an
entity
in
a
video
game
or
like
a
renderable
entity,
or
it
was
an
actual
physical
set
of
hardware
that
you
were
sending
orders
to.
A
Obviously
that's
not
very
tractable
to
mock
sorry
to
test
and
in
an
automated
fashion.
So
we
mock
this
out
and
again.
If
this
actuator
will
say
a
trait
so,
for
example,
it
could
have
many
actions,
one
of
them
being
moved
forward.
This
policy
would
realistically
have
lots
more
nuanced
actions,
but
for
the
purposes
of
illustration
move
forward
and
it
moves
by
forward
by
some
amount.
We
mock
this
as
we
did
before
we
use
mock
traits,
and
then
we
do
in
pull
actuator
for
mock
actuator.
A
The
robot
itself
in
this
case
takes
a
reference
to
the
actuator,
and
it
has
this.
Take
action
function
which
receives
some
world
states
again,
we
don't
care
about
the
exact
contents
of
it.
At
this
point,
we
just
receive
some
world
states
and
then
there's
some
business
logic
on
on
how
the
robot
decides,
what
actions
it
should
take-
and
this
is
a
thing
we
want
to
test
after
we've
done,
that
we
can
test
the
robot
by
again
instantiating
a
mock
actuator.
A
We
run
the
code
under
test
which
is
take
action,
and
then
we
assert
on
what
actions
the
robot
actually
took.
One
thing
to
note
here
is
that,
realistically
you
would
have
many
many
many
different
test
functions
or
with
different
world
states
or
to
test
and
poke
and
prod
and
and
test
how
this
robot
works.
Now.
A
The
issue
with
this
specific
example
is
robots
in
particular,
and
decision-making
is
quite
complicated
and
it's
quite
nuanced:
do
we
really
care
that
the
robot,
in
this
case
we're
setting?
Do
we
that
the
robot
moved
exactly
100
times?
Is
that
something
we
actually
care
about?
Do
we
care
that
it's
move
forward
a
little
bit
or
within
a
range?
We
might
not
actually
care
that
it's
exactly
100
units.
A
So
if
you
imagine
the
space
of
all
possible
behavior
that
the
robot
can
take
or
the
code
of
the
test
in
a
more
generic
fashion-
and
this
is
the
expected
behavior-
what
we've
just
done
is
we've
tightened
the
assertion
way
too
much.
So
now,
we've
artificially
constrained
the
test.
So
if
someone
decides
to
slightly
change
the
implementation
of
the
robot
and
how
it
makes
decisions,
so,
instead
of
moving
100,
it
moves
as
say
120.
A
That
might
still
be
within
a
realm
of
expected,
but
it
will
break
the
test
because
it's
moved
out
of
that
tight
assertive
space.
So
what
we
really
want
is
I
expected
I'll
set
it
to
be
the
same,
so
basically,
behavior
verification
can
over
fit
the
implementation
and
the
lack
of
tooling
and
good
ways
of
of
matching
and
argument
values
makes
us
more
likely.
So
let's
talk
about
pattern
matching
so,
rather
than
match
arguments
to
values,
you
match
them
to
actual
more
generic
patterns,
so
we
have
called
with
pattern.
A
So
you
can
say
actuator,
don't
move
forward
called
with
pattern
and
you
pass
in
some
matching
function.
So
here
we
had
is
greater
than
or
equal
to.
100
this
takes
the
argument
being
matched
and
then
it
runs,
some
check
say
are
greater
than
equals,
100
returning
true
if
the
value
is
matched
and
false,
otherwise,
now
obviously
rotten
handwriting
a
bunch
of
closures.
All
the
time
is
probably
not
ideal.
It's
very
verbose,
and
it's
quite
painful,
so
you
get
around
this
with
parameterised
matcher
butchers.
A
So,
for
example,
you
would
have
a
greater
than
or
equal
to
function.
This
is
a
generic
function
that
can
take
any
type
that
implements
partial,
eq
and
partial,
or
in
other
words,
any
type
that
you
can
say
greater
than
you
pull
on.
It
takes
a
single
parameter.
The
first
argument
is
the
the
value
being
matched
and
it
takes
a
single
parameter
base,
though,
which
is
actually
what
it
does
here
like
what
the
base
value
should
be,
and
so
now,
instead
of
actually
generating
a
so
manually,
writing
all
of
our
matches.
A
We
can
just
use
a
macro
called
P,
which
is
defined
in
double
to
basically
generate
these
matching
closures
for
us.
So
this
generates
matching
closures
on
the
fly
by
you
saying,
take
this
parameter
rise,
match
of
GE
and
then
100,
and
so
what
this
code
looks
like
is
pretty
much
the
same,
so
we
have
P
GE,
100
and
then
matcher
and
there's
loads
of
built-in
matches.
There's
wildcard
matches.
If
you
don't
care
about
specific
arguments,
comparisons
floating
points
string
matches
container
matches.
You
also
compose
matches
together.
A
So
you
can
say:
maybe
you
don't
care
that
the
robot
moved
just
to
point
more
than
100,
but
then
it
moved
within
some
range.
So
you
can
say
it
matches
all
of
greater
than
equal
to
100
lower
than
equal
to
200.
You
can
also-
and
this
is
particularly
useful
feature
is,
do-
is
do
matching
across
individual
elements
in
the
collection,
so
any
iterable
an
iterable
object
it.
You
can
use
this
each
match.
A
For
me,
I
didn't
have
that
option,
so
I
needed
to
go
with
something
that
could
only
use
stable
features
and
the
second
one
was
no
changes
to
production
code.
Now,
it's
okay
to
refactor
your
code
to
make
it
more
testable,
but
actually
adding
extra
awkward
boilerplate
to
the
code
just
to
make
it
testable
always.
A
So
with
this,
you
can
actually
mock
any
arbitrary
trait
from
any
library,
and
it
doesn't
matter-
and
these
are
challenging
goals
again,
because
that
should
the
the
original
talk
that
I
had
was
the
second
part
of
it
was
20
minutes
purely
on
why
this
was
so
challenging.
But
sadly
we
don't
have
time,
but
I
would
love
to
discuss
it,
but
basically
it's
really
really
difficult
and
it's
partly
in
because
Russell's
as
a
compiler
is
so
strict
that
it
actually
makes
all
this
automatic
code
generation
and
generic
mock
functionality
quite
difficult.
One
thing
this
was
Pattinson.
A
This
was
inspired
by
was
Google
mock.
So,
if
any
of
you
view
c++
google
mock
is
an
amazing
mocking
framework,
but
it
cheats
in
some
ways
that
the
borrow
check
of
caches,
which
is
quite
frustrating
but
also
a
good
thing
as
well.
So
as
eventually
most
mocking
libraries
require
nightly
and
pretty
much
all
I
found
required
production
code
change
that
you
at
least
have
to
annotate
the
trace
that
you
want
to
mock,
but
there
is
a
cost
to
actually
achieving
those
two
goals,
and
that
is
the
slightly
more
verbose
generation.
A
So,
as
you
saw
earlier,
there
was
two
macros.
There
was
more
trait
and
mock
method
and
so
basically
add
to
repeat
yourself
twice
and
there's
limitations
in
the
current
rust,
stable
version
that
basically
make
it
impossible.
If
you
don't
want
any
production
code
changes
to
to
to
merge
those
two
macros
together,
it's
a
specific
feature,
I'm
waiting
for
which
is
generic
specialization,
which
will
make
this
problem
go
away
and
once
that
does
they
can
be
merged.
But
until
that
point
it
is
slightly
more
of
a
base
and
that's
pretty
much.
A
However,
using
mocking
can
often
overfit
the
implementation,
so
you
need
to
be
very,
very
careful
and
you
need
to
have
good
tools
that
enable
you
to
make
these
more
nuanced
assertions.
Not
just
you
record
with
exactly
this.
You
need
to
have
these
more
looser
assertions
so
that
your
developers
don't
hate
their
lives
a
year
in
the
project
and
have
to
constantly
change
test
code.
All
the
time
when
they
slightly
change
it,
implementation
double
is
a
crate
that
generates
these
these
traits
and
functions.
A
There's
a
wide
array
of
behaviors
and
setups
I
only
actually
covered
a
very
small
subset
of
the
overall
set
of
features,
and
it
has
first
class
mashup
at
mashing
support.
That
was
the
biggest
reason
I
actually
made.
This
library
was
because
pattern
matching
and
roster
staple
pretty
much.
It
requires
no
changes
to
production
code,
but
that
does
come
at
a
cost.
These
are
some
alternative
mocking
libraries
that
I
recommend
checking
out
after
this
talk,
depending
on
your
use
case,
you
might
actually
find
these
are
a
lot
easier
to
use
for
you.
A
A
Yeah
yeah,
it
was
like
I
think
one
of
the
reasons
why
mocking
and
testing
so
big
in
turn
and
inside
languages,
because
you
can't
rely
on
the
compiler
or
when
you've
got
something
like
rust,
yeah
you're
doing
learn,
never
systems.
Often
you
don't
actually
need
to
I,
still
I
still
found
even
doing
like
quite
low
level,
at
least
to
C++.
Anyway,
I've
still
found
that
mocking
has
its
uses,
but
definitely
you
can
/.
You
can
overuse
it
right.
So
you
say
it's
very
suppose.
A
Your
hypotheses,
you
could
have
a
yes
you
could
you
could
do
that?
Yes,
yeah.
The
reason
I
decided
not
to
go
with
that
approach
was
like
I
personally
preferred
the
idea
of
having
like
an
isolated
library,
yeah
I,
having
to
require
the
users
to
have
like
an
extra
step
in
their
tool
chain
was
kind
of
I.
Don't
know
for
me,
you
just
kind
of
have
it
all
quick,
you
know
I,
don't
you
but
I,
understand
I.
A
Think
it'll
be
call
a
lot
more,
a
lot,
a
lot
better
when,
when
rust,
macros
2.0
class
yeah,
so
there's
that
and
there's
also
the
actual
reason
why
they
can't
be
merged
is
because
in
if
you've
got
macros,
you're
you're
matching
to
the
T
Y
token.
But
when
you're
storing
what
you've
been
called
with,
you
want
to
store
the
raw
value
type.
So
if
you
have
say
a
reference
to
an
integer,
so
you
got
like
a
reference
to
an
integer
yeah.
Then
you
can't
decayed
I
want
more
secrets.
Yes,.