►
From YouTube: Virtual User Group - Writing Tests For Core
Description
A introduction to Simple Test.
A
Recording
is
on
cool
all
right,
welcome
everyone.
This
is
the
tuesday
july
27th
virtual
users
group
for
backdrop.
The
plan
today
is
to
cover
automated
testing.
Specifically,
I
think,
we're
gonna.
The
plan
was
to
go
over
a
simple
test,
but
we
could
cover
other
things.
If
people
want
to
talk
about
that
as
well,
do
we
want
to
have
everyone
introduce
themselves.
B
It's
usually
a
good
idea.
It's
weird
circumstances.
Today:
okay,
but
I'll
go
ahead
and
introduce
myself
quick.
Since
I'm
talking,
I'm
tim,
I'm
in
deerwood
minnesota.
I
was
supposed
to
host
this
meeting
today,
but
my
power
died.
So
I'm
coming
to
you
on
my
phone
yeah
and
good
luck
and
because
you're
probably
going
to
lose
me
as
soon
as
my
phone
runs
out
of
power,
I'm
going
to
be
gone
so
anyways
go
ahead.
A
All
right
thanks,
I'm
joseph
flatt,
I'm
in
las
vegas
nevada
and
I
volunteered
to
host
this
meeting,
because
I've
done
a
bunch
of
stuff
with
a
simple
test
framework
in
backdrop,
although
I
would
not
consider
myself
by
any
means
an
expert
on
the
subject.
C
Sure
I'm
luke
mccormick,
I'm
a
one-time
programmer
occasionally
product
manager
and
project
manager
and
other
kinds
of
things
like
that
in
san
ramon.
California,
I've
never
written
any
tests,
and
I
really
should
so
that.
That's
why
I'm
here
to
try
to
level
up
there?
How
about
peter.
D
Peter
bw
panda
in
australia
and
I'm
interested
in
tests
because
I'm
often
writing
code
or
contributing
like
pull,
requests
and
stuff,
and
then
they
need
tests
written.
But
I've
not
done
it
before
and
it's
a
bit
confusing
so
interested
to
learn
more
so
I
can
contribute
more
and
robert.
E
Thanks,
I'm
robert
lyon
plug
folder
on
the
internet.
It
sounds
like
I'm
in
similar
boat
as
some
of
the
others.
I've
done
a
little
bit
of
tinkering
with
simple
tests,
because
some
of
the
modules
I
quoted
had
tests
in
drupal
and
needed
work
to
get
them
running
in
backdrop.
It
was
a
little
painful,
so
I'm
hoping
to
pick
up
some
tips
and
techniques
and
knowledge
here.
That'll
make
that
process
a
little
less
painful
for
future
development.
A
A
A
And
then,
once
you
have
done
that
under
development,
there
will
be
this
testing
link
and
you
can
go
here
to
see
all
of
the
tests
that
are
provided
by
any
modules
you
have
installed
or
or
by
any
profiles
you
have
installed,
and
so
this
is
a
basically
a
stock
backdrop
site.
So
all
of
these
tests
are
provided
by
backdrop,
and
they
essentially
are
what
we
run
on
every
time
you
make
up
every
time.
Someone
makes
a
pull
request
to
backdrop.
A
You
can
so
each
of
these
groups
can
potentially
have
a
bunch
of
tests
under
them
and
there
are
so.
These
are
basically,
these
are
integration
tests,
so
they're
not
like
unit
tests
like
php
unit,
which
test
only
a
single
function
or
a
single
class,
or
something
like
that.
These
test,
the
entire
backdrop
infrastructure
as
a
as
a
complete
unit,
and
because
of
that
they
have
to
set
up
a
database
whenever
they
test
to
run
so
sometimes
they
are
a
bit
slow.
A
A
A
So
you'll
have
this,
which
is
the
name
of
your
class
and
then
you'll
have
a
human,
readable
name
and
a
description,
and
then
you'll
have
a
group
which
is
these
group
categories
here
and
then
you'll
have
the
file
that
it's
in,
and
so
this
information
here
is
in
drupal
7
used
to
be
in
a
function
in
your
test
class.
But
now
it's
in
an
info
file.
C
A
And
so
in
this
case,
and
there
they're
basically
two
functions
at
a
minimum
that
you
need.
One
is
your
setup
function
which
you
actually,
if
you
don't
need
to
do
anything
you
don't
you
can
exclude
it
and
it'll
just
run
your
parents
setup
function,
but
if
you
want
to
enable
modules
before
it
runs
your
test
or
if
you
want
to
change
a
setting
before
the
test
run
that
you
would
do
that
here
in
your
setup
function
and
then
you
would
need
a
you
need
a
function
in
your
in
your
class.
A
A
A
Okay,
this
is
what
it's
supposed
to
do,
so
we
can
see
it
tells
you
how
long
it
took
to
run
the
batch
of
tests.
You
selected
and
it'll
give
you
information
about
it,
and
then
we
can
open
this
up
and
see
each
error
or
debug
message
or
each
test
assertion
will
have
its
own
line
in
here.
A
And
so
the
assertions
are
basically
these
assert
equal
or
assert,
not
equal.
In
this
case,
there
are
two
classes.
There
are
two
classes
that
backdrop
provides
that
you
can
extend
to
build
your
classes.
One
is
this
backdrop
web
test
case,
which
will
do
a
full
install
of
backdrop
and
provide
you
with
a
clean
environment
for
every
test
function
that
it
runs
and
then
there's
backdrop
unit
test
case
which
doesn't
which
actually
skips
the
whole
database
process.
A
A
Checking
the
values,
so
they
have
asserts,
which
you
put
a
true
false
value,
assert
equal,
which
you
give
two
values
and
I'll
check
assert
false,
which
is
essentially
the
opposite
of
assert.
So
this
will
check
for
a
true
value
and
this
will
check
for
a
false
value,
and
so
it
has
a
lot
of
built-in
functions
to
test
whether
or
not
something
has
successfully
happened
and
any
time
you
call
any
of
those
assert
functions.
It
will
have
a
message
that
prints
out
to
the
screen.
A
Fail
yep,
so
it
gives
you
a
red
message
says
that
there
was
one
failure,
so
that
that
is
essentially
what
it
looks
like
when
your
assertions
don't.
D
This
is
something
I
always
struggled
with
initially
with
tests
and
I'm
more
used
to
it
now,
but
initially
I
was
very
confused
like
when
you're
running
like
doing
a
pull
request
or
something
and
you're
seeing
these
messages,
not
in
maybe
a
backdrop
cycle
on
the
git
hub
or
something
you
see,
fail
value
a
is
equal
to
value
b.
It's
like
well,
no,
it's
not
they're
different,
but
the
message
is
saying
what
should
happen.
D
A
A
So
with
there's
this
optional
message
that
you
can
provide
a
message
if
it's
weird
or
unclear,
but
in
most
cases
that's
not
provided,
and
it
just
has
a
default
message.
That
is
just
what
it
expected
to
happen
and
not
what
actually
happened
in
a
few
cases
they're
like
where
the
tests
are
really
complicated,
they
have
actually
useful
messages
but
yeah
you're
right.
There
are
a
lot
of
places
where
it's
counter-intuitive,
like
what
you're.
A
Looking
for
one
thing,
that's
very
helpful
when
you're
writing
tests
is
that
there
is
a
debug
function
and
this
works
pretty
much
everywhere
in
backdrop.
A
A
A
A
A
So
so
yeah,
so
this
is
basically
your
bare
minimum
of
what
you
need
to
get
a
test
to
show
up
in
the
interface
and
run,
and
now
I
can
go,
take
a
look.
I
can
go
show
some
other
tests.
E
A
Oh
yeah,
a
random
name
is
used
like
all
over
the
place
and
it
literally
just
returns.
I
think
it's
an
eight
character
string.
A
A
A
A
With
this,
you'd
use
the
same
path
for
the
form
and
then
you'd
use
the
edit,
which
is
basically
all
the
the
names
it'll
be
the
name
property
of
a
field,
and
then
the
value
that
you
want
the
field
to
be
in
your
array
and
then
your
submit
is
the
name
of
the
button.
You
want
it
to
click
and
that
will
be
able
to
submit
a
form.
A
Actually,
I
think
I
can
node
dot
test.
I
think,
there's
actually
an
example
here.
A
Oh
here
we
go
here
is
the
test
in
the
node
module
that
tests
the
edit
page
and
so
here's
the
example
where
it
has.
It
creates
this
array
where
it
gets
the
it
actually
randomly
generates
the
some
things
sometimes
so.
It'll
dynamically
generate
these
edit
values,
sometimes,
but
here
it's
just
title
and
then
the
body
and
it's
setting
two
values
and
then
it's
doing
the
post.
A
And
then
here
it
has
a
click
link
edit.
So
what
it
does
is
every
time
you
do
a
backdrop
get
or
a
backdrop
post
or
anything
that
simulates
loading
a
page
it'll
store
that
page
in
a
in
a
variable,
and
then
you
can
use
this
click
link
to
just
click
anything
on
the
page
link.
So
if
you
know
it's
there,
you
just
click
link
in
the
name
of
the
link
and
it'll.
Just
do
it
and
load
a
new
page
and
put
that
new
page
in
that
variable.
A
A
A
A
A
A
You
can
actually
put
whatever
you
want
into
this
database
table
and
whatever
you
put
in
there
will
get
displayed
here
as
new
lines,
and
it's
just
as
long
as
you
have
all
the
fields
filled
in
it'll.
It
should
work.
A
A
D
D
A
Hear
it
very
clearly,
so
I
believe
peter's
question
was,
if
you
have
multiple
test
functions
in
the
same
class,
that
they're
discrete
from
each
other
and
don't
have
information
passed
between
them?
A
A
A
A
A
All
right
here,
so
this
is
basically
xh
prof,
like
a
user
interface
on
it.
A
D
A
A
I
would
probably
run
them
all
together
because
it'd
be
a
lot
faster,
but
there
are
some
cases
where
you
don't
want
that
to
happen,
especially
if
you.
A
That
would
be
an
example.
I
think
they
do
that.
A
lot
in
views
like
they'll
set
up
there's
a
test
for
almost
every
single
setting
in
the
views
ui
and
for
a
lot
of
those
tests.
They
don't
want
it.
They
affect
the
output
of
the
html
on
the
page
and
they
don't
want
one
test
settings
to
interfere
with
another
test
settings,
and
so
so,
if
you
go
through
these
there's
actually
a
couple
hundred,
I
think
test
functions
and
views.
A
A
A
Process
did
anyone
else,
have
any
questions
or.
A
F
Yeah,
maybe
I
can
help
a
bit
there,
so
I
don't
know
the
technical
description
for
xpath.
But
essentially,
if
you
do
an
x-path
assertion,
it
actually
tries
to
match
actual
page
strings
as
opposed
to
doing
any
sort
of
php
operation.
So,
for
example,
I
have
sorry
I'm
chewing
gum.
At
the
same
time,
I
have
an
extension
for
chrome
called
xpather
that
I
use
to
make
that
that's
quite
useful
when
you're
trying
to
write
a
expat
test.
F
Maybe
you
can
try
that
so,
for
example,
if
you
want
to
test
to
see
if
a
particular
string
is
appears
on
a
page
say,
for
example,
you
want
to
see
if
the
expression
the
content
type
has
been
created.
For
example,
you
could
do
an
xpath
expression
that
will
find
that
particular
string.
But
if
you
wanted
to
find
the
actual
html,
you
can
write
an
xpath
expression
that
finds
not
just
the
words
in
that
string.
F
F
E
A
A
F
Yeah,
it's
it's
not
really
based
on
regular
expressions.
I
don't
think
it
is.
It
has
its
x
path.
Tense
seems
to
have
its
own
sort
of
language
that
it
uses
to
define
expressions
on
the
page
or
find.
A
A
A
A
E
F
Yeah,
so
you
can
actually
an
expat
expression
that
says,
find
an
element:
a
div,
for
example,
with
this
particular
class
and
check
to
see
if
there
is
a
another
div
with
that
particular
class
within
it,
and
check
to
see,
if
there's
a
text
text
with
this
particular
string
within
that,
so
it
can
be
quite
complex
and
you
can
search
for
different
string,
different
elements
within
different
elements.
E
It's
kind
of
a
jquery
for
php.
E
F
So
I'm
I
I
was
just
looking
at
and
just
to
find
an
example,
for
example,
on
node
node.test,
for
example,
there's
a
there's,
an
xpath
query
that
says
find
an
a
tag
which
contains
a
reference
to
the
page
test
view
feed.
F
E
E
A
A
Oh,
there
are
a
lot
of
other
tests
where
they
just
check
that
the
text
is
anywhere
on
the
page,
especially
with
if
they're
testing,
for
like
error.
D
So
joseph
I
got
a
question
about
all
the
different
like.
I
said
this
assert
that
or
backdrop
all
the
different.
What
are
they
called
functions?
What
are
they
called?
I'm
not
that
great
with
object,
oriented
code.
Your
editor
brings
up
the
list
of
all
of
them
as
you're
typing,
but
for
those
of
us
that
don't
have
that,
can
you
show
us
where
we
would
find
out
what
options
there
are
to
use
for
different
things?
Sure.
So,
if
you
go
to.
A
Core,
can
you
guys
see
this?
I
don't
know
this
might
be
small.
A
A
This
is
this:
is
an
editor
called
netbeans,
it's
kind
of
old.
It's
like
a
java
editor,
it's
not
actually
designed
for
php.
So
it
has
some
weird
quirks
and
I'll
just
say.
If
you
go
into
core
modules
and
then
simple
test,
there
is
a
php
file
here
called
backdropwebtestcase.php,
and
that
is
where
those
two
classes
that
you
can
extend
live
and
if
you
go,
oh,
oh,
it's
already
open
and
if
so,.
A
Or
or
most
of
them,
so
this
test
case
one
has
a
lot
of
those
helper
functions.
Checking
your
requirements
so
like
it
depends
on
curl.
So
it'll
do
that
and
you
know
oh,
it
also
contains
the
stuff
for
actually
setting
up
the
database.
Prefixes.
A
So
yeah
so
that'd
be
just
down
here
insert
a
certain
delete,
assert
various
things.
A
A
Basically,
helper
functions
to
put
stuff
into
that
table
that
stores
all
of
the
log
messages
that
get
printed
out
for
your
test
and
yeah.
So
so
you
don't
have
to
write
your
own
database
query
stuff
to
put
stuff
into
that
table.
You
can
just
if
you
need
something
to
be
printed
out,
you
just
you
call
this
function
and
put
it
in
there.
A
So
yeah
anything
else,
anyone
wants
to
talk.
A
F
All
right,
I
I
just
like
to
say
that
I
think
the
best
way
to
figure
this
out
really
is
to
just
write
some
tests.
F
Even
if
you
have
a
small
custom
module,
it's
useful
to
write
tests,
I
imagine
might
have
discussed
that,
but
you
can
figure
out
how
to
do
it
by
just
trying
to
do
it
and
it
it
actually
works
out.
Quite
simple.
Once
you
get
the
hang
of
the
the
backdrop
get
and
the
backdrop
posts,
then
the
rest
of
it
becomes
quite
reasonably
understandable
after
that,
but
I
would
encourage,
even
if
you
have
a
simple,
maybe
not
simple,
but
if
you
have
a
custom
module
or
any
module
at
all.
F
I
think
it's
useful
to
have
tests
just
to
make
sure
everything
works,
especially
when
you
want
things
to
work
with
multiple
users,
multiple
permissions,
rather
than
having
to
sign
out
and
sign
back
in
as
a
different
user.
You
could
just
write
a
test
and
give
different
users
different
permissions
and
change
things
submit
the
form
1000
times
2
000
times
to
see
what
happens.
I
think
that's
the
most
useful
thing
about
the
testing
framework.
For
me.
A
A
Or
permissions,
if
you,
if
you
need
a
specific
permission
to
be
assigned
to
a
user,
you
can
just
put
the
names
of
all
those
permissions
in
here.
D
A
A
And
yeah,
like
doc,
said
most
of
what
I've
learned
from
about
tests
has
been
from
just
porting
modules
that
have
tests
or
from
work
I've
done
to
try
and
make
the
test
framework
better
yeah.
I
just
kind
of
figured
it
out.
I
don't
know.
F
And
just
just
one
last
thing
I
mean,
I
don't
know
if
you
just,
I
missed
the
first
20
minutes,
but
I
don't
know
if
you
discussed
it,
but
the
way
I
think
about
writing
the
tests
is
just
imagine
that
you
are.
F
You
are
browsing
the
website
yourself
and
you're,
going
from
page
page
and
submitting
forms.
That's
essentially
what
tests
look
like
to
me
so
backdrop
get
means,
go
to
this
path
back
your
host
means
submit
this
form
and
that's
it.
So
if
you,
if
you
have
a
website-
and
you
want
to
know
how
it
works,
I
mean
you
have
a
writing
module
and
you
want
to
make
sure
that
it's
working
the
way
that
it's
supposed
to
you
just
imagine
that
this
is
the
the
the
page
that
my
module
provides.
F
D
A
Yeah,
that's
a
it's
a
big
hurdle
at
the
moment,
just
the
amount
of
time
it
takes
to
actually
run
them,
because
at
this
point
it's
basically
impossible
to
run
the
full
test
suite
on
your
local
machine,
because
it
tastes
like
an
hour
or
more.
A
A
A
All
right:
well,
I
think
if
no
one
else
has
anything
else
they
want
to
add.
I
guess
we're
done.