►
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
uh
virtual
users
group
for
backdrop.
uh
The
plan
today
is
to
cover
uh
automated
testing.
uh
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,
um
do
we
want
to
have
everyone
introduce
themselves.
B
It's
usually
a
good
idea.
um
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
uh
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
uh
anyways
go
ahead.
C
D
E
Thanks,
I'm
robert
lyon
plug
folder
on
the
internet.
uh
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.
um
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
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
And
so
the
assertions
are
um
basically
these
assert
equal
or
assert,
not
equal.
In
this
case,
um
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
uh
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.
D
um
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
um
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
um
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
A
A
A
E
A
A
A
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
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
um
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
A
D
A
A
A
A
A
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
A
F
Yeah,
maybe
I
can
help
a
bit
there,
so
I
don't
know
the
technical
uh
description
for
xpath.
But
essentially,
if
you
do
an
x-path
assertion,
it
actually
tries
to
match
actual
page
uh
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
A
A
A
A
E
E
F
E
E
A
D
So
joseph
I
got
a
question
about
um
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.
um
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
A
This
is
this:
is
an
editor
called
netbeans,
um
it's
kind
of
old.
It's
like
a
java
editor,
it's
not
actually
designed
for
php.
So
it
has
some
weird
quirks
um
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
uh
where
those
two
classes
that
you
can
extend
live
and
if
you
go,
oh,
oh,
it's
already
open
and
if
so,.
A
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
A
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
um
reasonably
understandable
after
that,
but
I
would
encourage,
even
if
you
have
a
simple,
uh
maybe
not
simple,
but
if
you
have
a
custom
module
or
any
module
at
all.
F
I
think
it's
useful
to
have
tests
um
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
um
framework.
For
me.
A
A
D
A
A
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.