►
From YouTube: MFTF Test Suites
Description
Agenda:
- What is Test Suite
- How it works in MFTF
- How to make use of Test Suites
A
B
All
right
cool,
yes,
so,
like
Jimmy
said,
the
topic
today
is
MF
TF,
Suites
and
using
Suites
and
I
want
this
to
be
a
guide
covering
basically
what
sweets
are
when
to
use
them
and
then
how
to
best
use
them
that
replicate
what
we
have
going
on
internally,
which
is
a
pretty
good
usage
of
sweets.
Yeah,
we
go
with
an
ever
increasing
number
of
MFT
f-test.
It's
important
having
a
mechanism
to
organize
and
consolidate
them
for
ease
of
use.
B
The
more
tests
there
are
the
harder
it
is
to
tell
what
I
need
to
run
when
in
sweets
are
the
best
way
to
accomplish
that.
But
what
is
this
week?
It's
a
collection
of
MFT
of
tests
that
allows
for
grouping
of
pre
and
post
conditions
for
a
set
of
over
the
included
set
of
tests,
and
you
can
include
you
can
determine
what
tests
are
in
the
suite,
via
inclusion,
exclusion,
groups
and
modules.
B
B
So
the
contents
of
the
suite
we've
seen
in
this
sweet
sample
here
we
have
a
before
block.
This
is
a
precondition.
The
after
block,
which
is
the
post,
condition
the
inclusion
block,
which
tells
the
suite
what
is
included
as
a
part
of
the
suite
and
the
exclusion
block
which
to
basically
filter
out
a
subset
of
what's
included
here
in.
B
Would
be
the
specific
test
that
comes
from
the
catalog
module
very
likely
so
once
include
the
entire
catalog
modules
where's
the
pests,
but
exclude
this
test
and
also
exclude
inside
the
catalog.
This
file
name
right
here
so
with
that
many
different
ways
of
including
and
excluding
what's
the
best
way
to
go
about
determining
what
a
sweeps
contents
are.
So
we
found
internally
throughout
its
use
and
throughout
its
lifetime.
That
groups
are
actually
the
absolute
best
way
of
determining
what
should
and
shouldn't
be
included
or
sweet
right.
B
So
when
I
say
groups,
I
mean,
let's
we
have
this
test
right
here
on
the
side
we
have
test
1
and
test
2
you
over
here
I
mean
this
group
tag
right
here.
The
best
way
to
think
about
what
a
group
tag
II
is
versus
a
sweet.
The
group
tag
is
literally
that
it's
a
pack
allows
you
to
tag
test,
one
with
the
group
a
so
that
anytime,
you
mentioned
group
a
test.
One
is
included
as
a
part
of
a
subset
right.
I
have
a
sweet,
a
right
here.
B
B
Well
internally,
let's
say
we
have
a
minimum
green
suite
and
the
minimum
green
suite
and
just
bear
cee
contains
ten
tests,
or
so,
if
we
have
another
extension
that
we
want
tests
from
that
extension
to
being
part
to
be
considered
part
of
the
minimum
green
suite,
we
can't
refer
to
those
tests
by
name
here
right,
because
the
the
suite
on
base
ee
will
not
know
that
the
extension
exists.
It
shouldn't
know
that
the
extensions
tests
exist
necessarily
so
then,
how
do
you
create
that
language
just
by
grouping?
B
B
B
B
This
could
pretty
much
be
considered
a
deprecated
path,
because
no
one
is
able
to
push
these
Suites
in
right
and
if
they
have
crossed
module
references
it
makes
them
really
tricky,
because
if
the
model
module
isn't
loaded
than
the
Suites
gonna
say,
I
can't
find
a
couple
of
my
tests,
or
neither
of
the
modules
are
loaded.
The
suite
still
exists,
it's
still
red
in,
but
they
don't
to
say,
hey.
The
suite
is
empty.
Why
do
I
exist?
B
A
B
Why
the
grouping
is
so
important?
You
can
still
check
in
the
suite
under
back-end
or
live
the
lowest
common
denominator
module
so
that
it's
that
it's
there
for
use
in
all
the
further
modules
and
generated
tests
from
Suites.
Our
output
under
definites
acceptance,
test
functional
for
Gento,
functional
test
generated
an
ensuite
name.
This
is
not
a
directory.
You
guys
should
be
having
to
mess
around
with
directly
too
much.
If
I'm
FDF
it's
doing
its
job,
it
should
stay
hidden
kind
of
in
the
backend,
since
everything
else
is
abstracted
out
on
top
of
it.
B
So
MFD
f,
suite
commands
generate
all
the
tests
within
a
specific
suite.
It's
just
a
generate
sweet,
sweet
name,
and
this
brackets
right
here
means
that
this
command
accepts
multiple
Suites
names
and
I'll
show
off
running.
All
of
these.
Mr.
Shute
show
off
this
functionality
here.
In
a
little
bit
run
all
tests
within
a
suite
is
run
group
and
then
the
sweet
name.
B
One
will
see
that
what
will
happen
is
test.
One
is
going
to
be
running
under
sweet
sweet
day
right
there.
It's
a
lot
of
scrolling
text,
but
I'll
just
go
back
up
to
show
you
guys
what's
happening.
We
see
beginning
of
execution
of
sweet
a
before
block,
then
beginning
execution
of
sweet,
a
complete
test,
one
block,
which
is
the
single
comment
that
I
hadn't
used
and
then
the
after
block
being
run
right
here.
So
you
can
do
run
tests
just
like
this.
B
If
the
test
exists
in
both
groups
or
more
than
one
suite
where
lakal
happen
is
that
it
will
run
the
test
in
every
suite
possible,
because
just
by
telling
it
I
want
to
run
test
one
and
if
that's
wrong
exists
in
multiple
Suites
there's
no
way
that
MF
DF
can
find
out
magically
which
context
we
wanted
to
run
in,
because
there
might
be
different
suite
preconditions
between
suite
a
and
suite
b
that
alter
the
magento
state
in
specific
conditions
right.
So
you
need
to
be
able
to
be
able
to
run
them
all.
B
The
good
news
is
and
not
included
in
this
PowerPoint
deck.
Something
that
we
have
coming
up
is
this,
which
I
think
is
already
much
more
developed
branch
and
will
properly
demo
the
whole
thing.
But
you
guys
can
see
these
syntax
of
it
was
sweet,
:,
test,
1
and
even
though
it
exists
in
sweet,
be
sweet.
Peas
not
being
run
here.
I
get
more
on
that,
whatever
we
demo
with
the
stuff
next
week,
but
just
a
sneak
peek
at
some
new
functionality.
B
So
here's
a
little
bit
of
a
visual
of
what
happens
whenever
you
run
tests
in
the
scope
of
a
sweet
right.
So
since
I
can
run
tests
within
the
scopes,
the
sweet
you
just
do
run
tests
a
the
sweet
ate
before
happens,
then
tests
inside
the
sweet
are
executed
and
then
the
sweet,
a
after
block,
happens
much
like
that.
Just
Shirdi
is
someone.
Tests
are
located
in
multiple
Suites
and
you
just
do
run
tests
a
and
run
test.
B.
B
You
can
see
the
test
day
as
part
of
two
Suites
has
to
be
as
part
of
Suite.
A
only
will
happen
is
this
will
execute
before
Suite
a
before
test
a
will
execute
test.
B
will
execute
and
then
Suite
a
is
done.
Using
move
on
to
the
next
appearance
of
test,
a
is
in
sweet
beats
and
then
doesn't
before
the
test
and
then
the
after.
It's
it's
basically
wanting
to
point
out
that
Suites
will
never
collide
with
one
another.
B
B
So
here's
a
pretty
fairly
big
point
when
do
I
use
Suites
right.
Basically,
these
three
different
points
to
organize
tests
that
need
budgets
would
be
configured
in
a
specific
way
say
something
like
switching
to
developer
mode
or
switching
to
production
mode
or
any
other
configuration
like
that
and
multiple
tests
are
going
to
be
doing
it.
You
want
to
save
time
instead
of
setting
it
up
and
then
cleaning
up
and
then
setting
it
up
and
cleaning
up.
You
can
just
do
it
once
for
multiple
tests.
B
Conclusion
of
Suites
by
module.
This
is
an
interesting
one.
I'm
just
gonna
do
better
if
to
have
a
run
group
and
then
suite
hey
again,
run
group
bear
with
us,
well
fix
it,
and
you
can
see
that
both
the
tests
inside
these
are
the
only
two
tests
that
live
inside
the
deadlocks
module
on
my
local.
Both
the
tests
were
executed,
preconditions,
test,
1,
test,
2,
post
conditions
and
then
we're
done
and.
B
B
Does
not
look
like
it
for
the
time
being,
at
least
well.
If
anybody
has
any
questions
on
on
Suites
internally,
we're
gonna
be
using
them
a
lot
more
coming
up
soon,
and
it
would
be
good
for
everybody
kind
of
on
the
same
page
as
to
their
use,
and
it
can
be.
It
can
be
a
bit
confusing
because
it's
it's
not
obvious,
necessarily
when
to
use
one
suite
versus
another
suite
versus
creating
a
new
suite
and
which
mechanisms
to
put
in
the
before
and
after.