►
From YouTube: Test Isolation and modularity. Why this is important?
Description
Best practices around test cleanup and some tips and tricks about test modularity.
A
Good
stuff,
let
me
go
ahead
and
share
my
screen
and
everybody
I'm
sharing
our
point:
nice
cool
yeah,
so
yeah
thanks
everybody
for
joining
again
assume.
You
said
it's
a
small
series
on
some
of
the
best
practices
on
FCFS
writing
and
everything
that
that
entails.
Obviously,
it's
not
going
to
be
an
exhaustive
list
of
every
single
possible
thing.
You
could
do
to
make
it
better,
but
it
should
be
a
good
starting
point
for
a
lot
of
people.
A
So
no
further
ado.
The
the
first
topic
that
we'll
be
covering
today
is
a
test
isolation,
so
in
content,
contentious
topic
that
a
lot
of
people
talk
about
since
it's
a
kind
of
a
pretty
hard
requirement
from
at
Dieppe,
and
it's
pretty
hard
to
achieve
so
I
want
to
demonstrate
some
of
the
easiest
ways
to
go
about
doing
that,
so
just
to
define
it
was
that
stuff's
Latian.
This
relation
refers
to
when
a
test
in
that
leaf
data
behind
appropriation
changes
in
magenta,
so
that
should
be
pretty
self-explanatory.
A
What
that
means,
it
means
deleting
products,
the
leading
categories,
living
users,
tax
rules,
whatever
entity
that
you
create,
or
whatever
changes
you
make
to
be
a
magenta,
and
since
you
should
try
to
undo
all
of
them
as
much
as
possible
before
your
test
is
considered.
You're
done.
So
a
full
definition
of
a
test
is
considered.
Isolation
or
isolated
is
if
it
does
not
leave
data
behind
dismal
a
magenta
figured
in
a
different
state
than
when
the
test
started
doesn't
affect
the
test.
A
So
just
diving
into
some
of
the
more
nuanced
topics
of
this
list
here
does
not
leave
behind
pretty
obvious,
doesn't
leave
or
get
to
configure
in
a
different
state
than
when
it
started.
Also
pretty
obvious,
it
doesn't
affect
the
following
test
outcome
self-explanatory
forever,
the
last
one
it
is
not
relying
in
regular
configuration
to
starts
preconditions
that
essentially
just
means
that
the
test
or
the
suite
actually
makes
changes
to
Magento
and
then
make
sure
that
the
test
is
ready
to
run.
A
The
reason
why
that
is
why
not
leave
the
CI
CD
environment
to
do
something
like
that
is
mostly
because
that's
the
whole
reason
why
we
have
Suites
and
stuff
like
that,
so
there's
built
in
methods
to
achieve
that.
So
why
is
this
inflation
important?
It's
important
because
for
isolation
kill
each
other
test
failures
right
for
the
test
view,
so
we
have
to
have
high
confidence
that
it's
actually
not
failing
randomly
or
because
of
tests
before
it.
A
And
if
you
introduce
a
test
that
has
education
problems,
you
can
invalidate
we
really
start
bringing
in
a
question
another
test
outcome,
so
Nina.
So
for
automation
to
be
useful,
you
need
to
be
able
to
do
spire
it
off
and
did
not
have
to
worry
and
scrutinize
every
single
test
outcome
to
make
absolutely
sure
that
other
the
sets
actually
fail
because
it
failed
ready
to
fail
because
another
test
before
it
did
something
with
Magento
instance.
A
That
would
cause
all
the
tests
afterwards
to
fail
right
and
then
you
have
to
get
into
the
weeds
of
looking
at
test
run
order.
And
then
you
have
to
start
taking
a
look
at
the
bill
more
closely,
and
some
of
those
artifacts
are
not
really
even
readable,
and
it
starts
to
basically
invalidate
the
whole
reason
why
you
have
automation
in
the
first
place,
so
the
big
and
difficult
portion
how
to
actually
achieve
test
isolation.
A
The
two
points
above
always
reviewed
the
starting
state
from
scratch
and
sure
that
each
test
cleans
up
properly
after
itself
are
the
overall
high-level
views
of
how
to
do
that.
And
yet
the
former
is
easier,
but
for
functional
test.
Rebuilding
the
database.
Each
time
can
add
a
lot
of
time
to
test
clean
up
or
a
test
run.
So
the
clean
up
strategy
is
much
more
practical
in
our
case
yeah.
A
If
you've
done
automation
at
all,
using
different
frameworks
grab
for
different
products,
you've
probably
used
that
strategy
of
just
rebuilding
the
database
every
time
or
running
against
oppression,
eroding
every
test
against
afresh
environment,
but
with
Magento
the
application.
That's
not
really
so
simple,
or
rather
we
have
found
that
that's
not
really
simple,
doing
like
a
snapshot
of
what
the
database
look
like
and
then
rebuilding
towards
it.
A
A
So
when
the
cleanup
approach
is
the
leading
versus
restoring
restoring
some
examples
of
entities
that
need
to
be
deleted
again
or
categories
products,
rules
like
car
price
rules,
product
price
rule
related
products
across
sell
users,
user
roles,
even
attributes
attribute
sets
basically,
whenever
you're,
in
a
test,
whenever
you're
going
to
be
creating
something
by
hand
or
like
like
using
an
action
group
to
create
a
product
or
something
in
your
after.
You
should
absolutely
have
the
delete
version
of
that
action.
A
Group
entities
of
your
score
restored,
store
configurations,
that's
the
kind
of
thing
that
you
need
to
take
a
look
at
what
the
default
state
of
Magento
normally
is,
so
that
you
can
restore
to
what
it
was
now.
One
of
the
difficulties
with
this
is
obviously
you.
What
are
you
going
to
be?
Are
you
going
to
kill
your
Magento
and
since
every
single
time
to
try
to
figure
out
what
the
store
figuration
is
or
what
the
default
set
is
kind
of
you
might
use?
A
This
is
a
simple
example
of
some
of
the
easy
go
to
use
for
cleaning
up
data,
so
if
you
see
that
there
to
create
data
into
before,
you
should
have
a
good
idea
leak
data
in
the
after
right.
You
can
see
in
this
example
the
before
create
data
for
creating
the
category,
there's
a
delete
category
in
the
after
that
matches
up
to
it.
So
you
just
have
a
one
to
one
relationship
and
in
this
test
there
is
a
create
data
in
the
body
as
well.
A
Then
you
can
see
right
away
that
that
there's
a
delete
data
in
the
after
as
well,
if
both
intestine
body
and
just
or
one
thing
to
note
as
well,
whenever
you're,
using
this
kind
of
strategy
of
matching
up
one-to-one,
create
data
to
delete
data,
you
may
want
to
delete
them
in
the
order
that
they
were
created
so
that
I
mean
category
comes.
First
was
the
was
created
first
technically
in
this
test
order.
A
If
you
might
need
to
understand
the
workflow,
if
you
see
that
there's
an
action
group
in
the
middle
of
it
that
is
going
to
create
a
category,
it's
not
a
create
data,
so
you
can't
match
it
up
one
to
one.
But
if
you
understand
the
test
flow,
it
should
be
pretty
obvious.
Oh
I
created
a
product
in
my
custom
website.
I
need
to
delete
it.
You
just
need
to
be
mindful
stuff,
like
that
comments
help
absolutely
if
you
just
create
xml
comments
around
general
block
of
code.
A
If
for
some
reason
they
can't
be
abstracted
out
to
action
groups
or
maybe
they're
a
part
of
multiple
different
action
groups,
if
you
just
create
a
human-readable
comment
in
case,
you
forget
to
clean
up
if
I,
if
I
were
to
pick
up
this
test,
I
would
look
to
see
if
there's
any
commenting
around
it.
Just
like
any
other
piece
of
code,
then
I
would
say:
okay,
cool
they're,
creating
a
category,
and
they
forgot
to
include
something
in
the
after.
So
I
just
need
to
do
something.
They're.
A
Cleaning
up
come
fix,
really
similar
strategy
to
the
create
data,
delete
data.
If
you're
using
a
magenta
CLI
command
to
change
a
configuration,
you
better
be
doing
that
in
the
after
as
well,
and
when
we're
talking
about
the
order
of
cleaning
up
in
general,
magenta
CLI
commands
I
would
say,
probably
should
be
one
of
the
first
things
to
be
cleaned
up.
If
possible,
it's
a
really
robust
command.
It's
generally
speaking
that
we're
just
going
to
randomly
fail,
since
all
its
steering
is,
you
know,
performing
rest
operations
against
the
back
end.
A
That
kind
of
stuff
is
really
robust
and
you
don't
need
to
worry
about
it.
Failing
in
the
middle
of
a
test
or
something
like
that,
obviously
some
cases
you
may
need
to
delete
your
entities
first
before
you
can
reset
the
configuration,
but
that's
another
rule
of
thumb
that
you
may
want
to
keep
in
mind.
A
A
If
this
is
being
done
in
the
test
number
one,
it
shouldn't
be
done
in
the
best.
You
see
the
CLI
command
way
more
robust
way,
fast,
very
saving
time
and
then
you're
saving
also
test
complexity.
The
number
two,
if
for
some
reason
this
is
part
of
an
action
group
or
it
doesn't
have
a
path
for
the
CLI
to
map
to,
for
some
reason,
you're
going
to
be
needing
to
do
CLI
commands
afterwards
to
clean
up
again
comments,
help
100%,
it's
so
much
easier.
A
Just
looking
at
this
and
seeing
this
little
chunk
with
it,
then
reading
this
chunk
of
code
and
examining
okay
like
this,
this
does
this
change.
The
configuration.
Does
this
game
configuration?
This
does
change
configuration
so
on
so
yeah.
Those
are
the
general
strategies
of
how
to
clean
them
up
clean
up
after
your
test.
Again,
it's
not
an
exhaustive
list
and
we
have
a
dev
Doc's
article
that
more
or
less
has
this
these
this
contents
of
these
destinies
bowler
for
quick,
that's
our
goal.
A
A
It
is
okay,
so
if
there's
no
questions
on
this
first
test,
isolation
on
it
did
that
one
can
is
a
little
straight
board
for
a
lot
of
people.
I
feel
tests.
Popularity
is
the
polar
opposite
of
that.
Isn't
that
very
straightforward
at
all,
it's
one
of
the
more
difficult
aspects
of
MSD
FX
should
be
able
to
do.
Let
me
just
open
this
in
the
desktop
app.
So
we
can
I
can
share
with
you
guys.
A
All
right
test,
modularity
man,
let's
just
dive
right
into
it.
What
is
test
modularity
when
it
comes
to
M?
If
yes,
test
material
merging,
is
basically
two
things,
there's
a
test
material
merging
that
we've
already
covered
extensively
in
Babcock's
under
merging,
so
I'm,
not
even
going
to
get
into
that,
and
it's
also
something
that
I'm
sure
most
people
who
use
them
IPF
understand
internally
and
externally.
But
the
second
point
of
it
is
the
mud
that
test
materials
are
modulars
themselves.
What
does
I
mean
des
materials
actually
being
correctly
owned
by
the
right?
A
Magento
module
and
the
tests
only
have
references
to
what
their
owner
Magento
module
has
a
dependency
on,
so
test
material
is
being
correctly
owned
by
the
right
Magento
module.
An
example
of
this
would
be
if
I'm,
operating
or
yeah.
It's
the.
If
I
need
to
create
a
create
category
page
and
create
a
bunch
of
elements
there
or
acting
groups
for
create
category
page.
That
means
that
that
stuff
should
belong.
A
Underneath
the
catalog
module
same
thing
for
out
of
editing
tax
rules,
that's
probably
gonna,
be
the
tax
module
in
that
tests
only
have
ever
reference
to
what
their
owner
Magento
modules
has
a
dependency
on.
That
means
that
if
my
test
is
doing
a
workflow
which
requires
a
catalog
to
be
on
and
requires
use
of
action
groups
or
something
like
that
from
catalog,
then
that
probably
means
that
the
module
where
this
test
lives
should
have
a
dependency
on
catalog.
Otherwise,
you
get
into
well
I'll,
get
into
it
a
little
bit
so
on
test
ownership
example.
A
So
this
is
from
admin
login
test.
You
can
see
that
the
first
acting
through
peer
login
as
admin,
is
referring
to
this
hacking
group,
so
we're
good
to
go.
Cuz
it's
in
the
same
module
right
back
in
to
back
in
sync
our
URL
and
the
login
page
dot
URL.
You
can
see
that
it
goes
to
admin.
Login
page
lives
under
back
end,
so
this
that's.
The
ownership
example
is
good
to
go.
A
Another
ownership
example
is
between
the
admin,
create
category
test,
so
we
can
see
one
of
the
first
things
that
it
does.
Is
it
logins?
The
admin
it
the
the
logins
I've
been
active,
comes
from
this
file
underneath
back-end,
and
you
can
see
in
the
composer
JSON
for
catalog
module
itself.
It
hardly
requires
magenta
go
back
in
so
you
should
not
have
any
problems
there
if
catalog
is
enabled
back-end
will
also.
Therefore,
it
has
to
be
enabled.
Therefore
this
is
a
safe
reference
to
make.
A
Now.
This
is
an
example
of
the
same
test.
We
don't
have
this
rule
violation
in
our
code
base
right
now,
thankfully,
but
this
catalog
test
right
here
having
a
grade
category
test
comes
from
catalog
and
there's
the
reference
to
this
really
long-winded
ad
downloadable
link
information
acting
group
right.
So
it's
for
downloadable
products,
and
then
you
can
see
that
this
acting
group
comes
from
this
file
and
the
downloadable
but
catalog
compose
a
JSON
has
absolutely
no
references
to
module
downloadable.
A
Therefore,
this
right
here
is
breaking
test
module
arity
in
the
sense
that
if
I
have
catalog
enabled
I
do
not
necessarily
have
downloadable
enabled
and
since
MFDs
uses
the
enabled
modules
in
the
magenta
instance
to
determine
what
to
read
and
what
to
not
read.
Then
that
means
that
this
test
may
fail
to
generate
under
specific
circumstances.
If,
for
some
reason,
I
disabled
downloadable,
product.
A
A
So
how
can
I
achieve
test
modularity?
This
is
very
difficult.
This
is
probably
one
of
the
most
difficult
parts
of
FTF,
because
it's
not
particularly
straightforward.
It
requires
a
lot
of
thinking.
He
requires
you
to
be
thinking
about
dependencies
of
the
modules
while
you're,
actually
writing
the
tests
themselves,
so
yeah.
So
the
first.
The
first
approach
is
intuition
is
not
really
an
approach
is
but
test
nomenclature
can
actually
lead
to
obvious
relationships
and
I
put
obvious
in
quotes
because
it
is
intuitive
it.
A
It's
probably
going
to
be
write,
a
good
percentage
of
the
time,
but
it
is
not
deterministic
so
yeah.
If
you
see
a
selector
that
has
tax
class
ID
right
right,
there
probably
belongs
to
the
tax
module.
Probably,
but
this
is
a
you
will
probably
need
to
double-check
this,
so
the
other
one,
the
other
approach,
instead
of
being
intuitive
you're,
actually
going
to
be
deducing
by
searching
through
the
Magento
or
extension
code
base.
You
use
portions
of
the
elements
determine
what
the
ownership
is
to
create
correct
correlations
to
portions
of
code
right.
A
So
this
is
a
little
top
to
down
example.
So
say:
I
need
to
be
interacting
with
the
add
attribute
button
right.
So
this
is
this
right.
Here
is
what
the
add
attribute
button
looks
like
in
the
source
of
the
page
and
that
I
see
pretty
immediately
that
it
actually
has
an
ID
is
right
away.
So
if
I
search
for
ID
equals
add
attribute
like
this
on
the
code
base,
it
leads
me
to
these
four
files
inside
Magento.
So
this
one
is
an
EM
fdf
section.
You
don't
need
to
worry
about
it.
A
This
is
an
MFT
F
section.
Don't
need
to
worry
about
it.
This
is
an
MFT
F
action
group.
Don't
need
to
worry
about
it,
but
right
here
you
see
that
underneath
catalog
view
admin,
HTML,
there's
a
UI
component
product
formed
XML
right
here
that
it
mentions
a
button
specifically
by
the
name
of
add,
attribute
and
gives
it
the
class
of
edit
button
hat
attribute
right
so
based
on
a
small
search
like
that,
you
can
pretty
much
link
directly,
ok,
so
this
right
here
should
definitely
belong
underneath
the
catalog.
A
So,
whenever
I
create
this
attribute
and
I'm
using
my
test,
then
my
test
needs
to
have
some
sort
of
dependency
to
catalog
yeah.
So
before
I
move
on
this
is
again
one
of
the
trickiest
parts
of
the
framework,
but
it
is
something
that
you
can
do.
You
can
try
to
rely
on
titles
on
IDs
and
stuff
like
that
data
UI
IDs
can
be
somewhat
useful
as
well,
but
generally
ID
and
title
are
going
to
be
the
unique
identifiers
that
lead
you
directly
to
where
your
tests
are,
where
the
material
should
actually
live.
A
So
the
last
double
check
that
M
F
DF
actually
includes
is
the
venom
F
DF
static,
chics
command,
so
it
basically
just
does
a
test
material
ownership
check
it
just
it.
Parses
two
tests
finds
all
the
different
references
that
the
test
has
and
then
double
checks
that
the
module
relationship
is
at
least
correct.
A
It's
useful
for
quick
feedback,
but
obviously
it's
not
magic
not
going
to
find
out
exactly
where
every
test
material
supposed
to
live,
but
it's
just
going
to
make
sure
that
at
least
the
test
references
aren't
broken
as
of
right
now
the
static
check
isn't
isn't
part
of
our
static
check,
build
or
anything
like
that.
It's
not
built
into
the
CI
CD,
mostly
because
we
do
have
some
violations
that
we
need
to
take
care
of
before
we
can
call
this.
The
gold
standard
at
everybody
100%
needs
to
follow.
A
Also
I,
don't
think
this
static,
Strix
command
is
being
used
extensively
by
anybody
outside
of
the
occasional
spot
check
from
mqe
and
I
think
from
implementation.
What
it's
actually
doing
is
it's
actually
building
out
the
dependency
tree
in
full,
meaning
that,
if
you
have
let's
say
your,
the
module
has
a
dependency
to
store
store,
has
a
bunch
of
dependent
other
dependencies
in
Magento.
A
So
there's
like
a
base
set
of
modules
that
almost
always
are
part
of
the
dependency
tree
I
think
there
were
some
talks
internally,
whether
or
not
we
wanted
to
build
out
that
full
dependency
tree
or
just
use
explicit
naming
right.
So
if
store
or
fires
back-end,
and
for
some
reason
my
module
doesn't
require
back-end
by
name,
then
it
would
need
to
require
back
in
by
name
toward
to
pass
a
static
check.
A
But
yeah
give
this
give
this
command
a
shot,
and
let
us
know
what
you
guys
think
try
to
make
some
direct
violations.
Obviously,
we
check
to
see
that
it
works
and
it
does
work,
but
the
the
feedback
of
these
static
checks
is
probably
going
to
be
the
thing
that
we
need
the
most
feedback
from
you
guys
on
to
make
sure
that
it's
actually
helpful
and
useful,
because
this
is
again
something
hard
to
achieve.
But
it
is
very
important.
A
A
But
yeah,
if
anybody
has
any
questions
on
any
of
the
two
topics
that
we
covered
today
feel
free
to
ask
them
in
the
MFD
F
channel
feel
free
to
ask
them
in
pangolins
or
the
MQB
team
feel
free
to
honestly
ping.
Anybody,
if
you
have
any
questions
about
it
or
something
about
that.
What's
unclear
that
you
guys
don't
want
to
ask
in
the
Whole
meeting
setting
we're
always
more
than
happy
to
help
you
guys
but
achieve
the
golden
standard
that
we're
all
shooting
for
or
MFDs
test
writing.