►
Description
In this video, our Dan Davison Sr. Test Automation Engineer gives a demo on how we implemented dynamic locator validation in our Ruby Page Objects.
A
A
A
My
goodness,
we
always
start
from
scratch,
so
you
have
a
page
in
our
page
object
and
we
have
elements
on
each
of
you.
Basically,
what
the
dynamic
page
old
validation
will
do
is
check
for
each
required
true,
ideally,
this
will
be
where
this
will
be
R
even
required
anymore.
It'll
actually
be
the
inverse.
So
let's
say
that
paid
the
password
field
right
here
wouldn't
be
required.
A
A
A
So,
let's
take
a
look
at
it.
Real
quick,
so
it'll
basically
visit
the
address
of
the
page
and
then
it'll
validate
that
the
elements
are
present
on
that
page
and
that's
the
key
right
there.
So
basically
it'll
scan
every
single
element
of
Luggin
page
so
from
the
mom.
Excuse
me
from
the
login
spec.
We
expect
to
land
on
the
login
page
right
so
on
the
login
page
that
class
it
scans
each
one
that's
required,
and
if
that
element
isn't
present,
then
it'll
raise
an
exception.
A
Saying
you're
not
on
that
page,
like
you
thought
you
were
so
if
we
needed
to
let's
say,
for
example,
the
sign-in
tab.
It's
gonna
be
dangerous
on
this.
This
saina
I'm
trying
the
logon
page
because
the
tabs
can
be
shifted,
say,
for
example,
LDAP.
It
might
default
to
LDAP
so
stuff
like
this.
We
won't
be
requiring
by
default,
because
this
could
this
could
be
defaulting
some
other
location.
Let's
see.
B
A
The
one
thing
I
am
missing
is
documentation
on
this,
so
in
the
mr
I
might
do
it
after
I
probably
should
do
it
with,
but
I'm
gonna
have
to
put
it
in
the
QA
director
we're
gonna
have
to
let
security
director
show
the
cute
project
is
the
document
how
this
validation
works
and
basically,
what's
going
to
happen
with
it
all
right
so
end
it
to
the
browser
visit
and
we're
on
belly
elements
present
right
here
on
the
login
page.
So
let's
go
ahead
and
step
into
and
check
it
out.
A
A
So,
basically,
that's
it
so
after
this
is
merged
in
I,
think
the
most
ideal
place
for
everyone
to
start
using.
This
is
going
to
be
when
they're
working
on
their
when
they're
touching
these
libraries.
Just
like
last
time,
we
were
kind
of
taking
all
out
of
the
the
bad
elements
and
such
let's
stop
this
debug.
A
Conditional
so,
for
example,
an
AJAX
load
after
you
press
button,
and
now
it
appears
that
wouldn't
be
required,
because
that's
a
conditional
element-
and
of
course
this
will
apply
to
all
pages
right
now,
because
the
the
little
dateable
as
a
module,
so
the
base
page,
extends
I'm.
Sorry
includes
I'm.
Sorry
does
extend
the
ability
to
both
module.
A
B
A
Trying
to
remember
where
it
is
now:
okay,
remember
you
big!
Yes,
that's
me,
that's
the
ideal
situation
where
all
elements
are
required
by
default
and
then
later
on,
it
fits
a
conditional
element.
Will
that
required
false
to
it
instead,
but
until
you
get
to
that
stage,
I
think
we
we
stick
with
this
and
then
that
way
we
can
kind
of
because
this
is
a
huge
change
and
we're
trying
to
make
it
as
little
as
possible.
So
I'm
yeah.
A
So,
basically,
that's
that's
pretty
much
it
and
I
think
they,
the
biggest
thing
like
I
said
as
soon
as
this
is
merging
in
you're,
able
to
start
using
it
so
think
about
the
rule
of
thumb.
Does
it
appear
on
the
page
once
you
end
up
there?
If
it
does,
it
needs
to
be
required,
and
then
oh
also
one
thing
so
the
visit
and
they
click
were
the
two
ella.
Where
were
the
two
functions
that
have
that
functionality?
So
if
we
look
back
at
base-
and
we
have
the
relevant.
A
A
So
that's
basically
what
it
is.
We
click
something
we
expect
something
to
happen
and
before
it
was
this,
and
it's
completely
fine
to
do
that,
and
then
we
expected
somewhere
so
page
main
menu
and
the
cool
thing
about
this,
like
I
said,
is
you
can
you
can
start
doing
all
kinds
of
stuff
with
the
click
element
you
can
put
the
stuff
in
there?
So,
like
I,
don't
know
some
other
some
page
and
you
could
commit
that
and
it
would
wouldn't
do
any
validation,
because
some
page
doesn't
have
any
required
elements
just
yet
identified.
That's
that's.
A
The
other
part
is
going
to
be
going
through
the
page
library
and
adding
the
required
elements
as
you
see
fit.
So
it's
going
to
be
a
slow,
progressive
change,
but
once
all
the
elements
in
the
libraries
are
identified
as
required
and
that
stuff
will
make
that
switch
and
delete
all
of
the
required
true
code
and
flip
that
flag
to
say
well,
everything
is
required
by
default.
A
B
A
Really,
no
because
visit
and
click
element
are
the
only
actionable
things
when
you
set
the
text.
It
really
doesn't
do
much
as
far
as
like
navigating
clicking
when
you
click
something
you
expect
something
to
happen.
You
expect
a
result
from
the
UI
and
that's
why
it
sits
there
on
clicking
woman
and
there's
I.
Don't
expect
it
to
be
on
any
other
function.
A
One
more
thing
to
add
to
this:
I'm
not
going
to
do
it
to
this,
mr,
but
I'm,
the
validate
able
when
you
click
an
element,
it's
going
to
be
ideal
that
we
wait
until
it's
clickable.
So
right
here
we
have
has
element
for
all
the
required
elements.
I'll
probably
have
another
condition
here
that
says:
wait
until
it's
also
clickable.
So
that
way
we
wait
for
any
animations
all
dynamically.
C
C
Is
it
it's
a
sequential
right
now,
where
you
have
a
list
of
required
elements
in
a
page
in
the
in
a
page
right,
it's
a
possible
to
do
like
a
concurrent
threading,
where
you
just
go,
find
these
five
elements
immediately,
a
person's
like
now,
it's
like
a
waterfall
that
finds
the
first
ones
and
when
it's
like
one
fails
and
it
fails,
or
do
you
see
any
performance
enhancements
here
in
the
future,
or
is
it
already
doing
it
a
synchronously?
So.
A
A
But
right
now,
as
far
as
the
performance
on
this
I,
don't
I
don't
expect
any
huge
performance
degradations.
If
anything,
it's
going
to
I.
Think
Zeff
actually
brought
this
up
in
that,
mr,
so
you
can
see
you
can
see
the
discussion,
but
I
don't
see
any
performance
degradation
because
sure
we
might
be
waiting
a
little
bit
longer,
but
that's
that's
necessary
in
order
to
make
sure
that
the
elements
aren't
there.
You
know
and
before
we
continue
the
test
and
if
of
course
they
aren't
yeah
it
breaks
immediately.
A
C
A
I
love
it
so
the
login
test
I
like
to
show
because
it's
real
quick
so
too,
we
look
right
there.
It
validated
that
we're
on
the
login
page
as
soon
as
we
click
that
sign-in
link.
It's
already
right.
Now
it's
on
the
validate
page,
there's
some
the
validate.
That's
making
sure
that
we're
there.
So
it's
all
happening
in
the
back.
There.
C
Very
cool
one
other
question
I
had
is:
do
we
foresee
any
change
to
the
base
page
structure
because
I
think
there's
a
question
unlike
inheritance
versus
composition,
where
you
want
to
just
extend
it
or
just
ingest
ingest
that
the
library
do
you
foresee
any
change
is
there
because
if
you
extend
it's
just
like
before,
get
everything
but
like
more
granular
pad
and
more
granular
patterns,
it's
a
big
compose
or
contain
each
library.
Instead,
do
you
have
any
thoughts
around
that
2014
framework.
A
C
A
C
You
foresee,
as
some
some
the
chasms
may
be
suitable
to
be
extended
from
which
is
depo
for
everything
going
forward,
but
some
mechanisms
may
be
just
you
just
compose
it
at
the
parent
level,
and
then
the
child
objects
will
have
the
the
child
objects.
Will
the
child
page
objects
will
contain
this
helper
function
instead
of
just
extending
from
it?
No.
A
I
think
this
is
applicable
to
everything
this
is
applicable
to
layers.
This
is
applicable
to
pages
any
UI
element
that
you
can
possibly
imagine.
It's
gonna
be
applicable
to
it
like,
even
when
you
click
the
profile
icon
on
the
top.
You
brings
up
that
layer
that
layer
right
there
is
also
going
to
be
validated
as
well.
When
you
click
that
profile
link,
you
expect
something
to
happen.
Where
do
you
expect
that
you
expect
that
layer
to
pop
up
so
profile
layer
and
then
it'll
validate
that
the
elements
are
there
before
you
continue.
B
A
C
A
This
was
my
original
implementation,
but
of
course
it
was
breaking
a
lot
of
things
because
of
that
situation
that
you
just
described
so
when
page
is
not
equal
to
know
when
page
equals
self
dot
last,
what
would
happen
is
it
would
validate
that
you're
still
on
the
same
page?
So,
for
example,
you
put
you
click
the
profile
link
and
you
didn't
specify
the
layer
to
validate
it'll,
validate
that
the
menu
or
the
main
page
is
still
there.
A
A
A
A
Okay
right
there
you'll
notice
that
it
hasn't
even
started
the
test,
yet
we've
gone
to
visit.
But
of
course,
now
it's
waiting
on
those
elements
now
and
there
we
go.
It
fails
with
the
message
password
confirmation,
then
that
appear
on
the
login'
pages
inspected.
So
this
is
kind
of
the
air
we
would
expect.
C
A
Oh,
and
it
reminds
me
MEC
of
the
question
you
asked
earlier
how
you
know
how
we
could
improve
that
this
is
another
thing.
So
right
now
it's
doing
it,
and
this
is
where
my
mind
was
going,
but
I
couldn't
really
articulate
it.
We
have,
let's
say
those
three
elements
as
required,
and
none
of
those
three
elements
appeared.
A
That's
where
the
performance
would
be
cool
because
we
would
be
able
to
instead
of
loop
through
each
one
and
then
fail
on
the
first
one
that
doesn't
appear.
We
check
all
the
elements
like
in
general
and
then,
whichever
ones
don't
appear
you
list
them
out,
basically
does
that
make
sense,
yeah
I,
think
that's
what
confirmation
it'll
say:
password
field
confirmation
and
change.
Bastard
wasn't
available.
A
C
A
C
I,
don't
I,
don't
mind,
no
I
mean
I
I
mean
iteration,
where
I
think
this
is
good
enough.
I'm,
just
gonna
slice
off
some
parts.
The
beginning
of
me,
that's
not
related.
Okay,
this
part,
so
they're
ready.
Okay,
if
I
blow
this
to
keep
leaven
future
and
you're
just
gonna
start
it.
Advertising
socializing,
awesome,
very
cool.