Web Application Testing with Selenium for DynDNS.com
Upcoming SlideShare
Loading in...5
×
 

Web Application Testing with Selenium for DynDNS.com

on

  • 4,828 views

Cory von Wallenstein walks through some best practices for using Selenium to test a large web site like DynDNS.com

Cory von Wallenstein walks through some best practices for using Selenium to test a large web site like DynDNS.com

Statistics

Views

Total Views
4,828
Views on SlideShare
4,202
Embed Views
626

Actions

Likes
1
Downloads
101
Comments
0

2 Embeds 626

http://www.standingonthebrink.com 613
http://www.slideshare.net 13

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Web Application Testing with Selenium for DynDNS.com Presentation Transcript

  • 1. Selenium
Seminar
 Cory
von
Wallenstein
 February
12,
2009

  • 2. Overview
 •  What
is
Selenium?
What
is
it
not?
 •  Selenium
as
a
support
and
bug‐report
tool
 •  High‐level
best
pracCces
 •  Under
the
hood
of
our
implementaCon

  • 3. UnigressificaConal
TesCng
 •  Terms
I
use,
exact
definiCons
debatable
 •  Unit
tesCng
 –  “Test
one
thing
in
isolaCon”
 •  Regression
tesCng
 –  “Test
one
thing
that
broke”
 •  FuncConal
tesCng
 –  “Test
things
working
together”
 •  VerificaCon
tesCng
 –  “Test
all
of
the
things
working
together”

  • 4. What’s
the
problem?
I
want
to…
 •  Test
the
code
 •  Test
that
the
code
produces
a
web
page
 •  Test
the
content
on
the
web
page
 •  Test
the
semanCc
meaning
of
the
content
on
the
 web
page
 •  Test
the
display
of
the
form
that
is
below
the
 content
on
the
web
page
 •  Test
the
display
of
the
form
that
is
above
the
 content
on
the
web
page

  • 5. What’s
the
problem?
I
want
to…
 •  Test
the
submission
of
the
form
with
invalid
data
 such
that
an
error
is
displayed
above
the
form
 (server
side
validaCon)
and
the
form
is
above
the
 content
on
the
web
page.
 •  Test
the
submission
of
the
form
with
invalid
data
 such
that
an
error
is
displayed
above
the
form
 with
client
side
validaCon
if
the
client
has
 JavaScript
and
server
side
validaCon
if
not
and
the
 form
is
above
the
content
on
the
web
page.



  • 6. What’s
the
problem?
I
want
to…
 •  Test
the
submission
of
the
form
with
invalid
data
 such
that
an
error
is
displayed
above
the
form
 with
client
side
validaCon
if
the
client
has
 JavaScript
and
server
side
validaCon
if
not
and
the
 form
is
above
the
content
on
the
web
page,
except
 for
IE6,
where
the
form
error
displays
below
the
 form.



  • 7. What’s
the
problem?
I
want
to…
 •  Test
the
submission
of
the
form
with
invalid
data
 such
that
an
error
is
displayed
above
the
form
 with
client
side
validaCon
if
the
client
has
 JavaScript
and
server
side
validaCon
if
not
and
the
 form
is
above
the
content
on
the
web
page,
except
 for
IE6,
where
the
form
error
displays
below
the
 form.
for
Firefox,
Safari,
Opera,
and
IE7,
but
 display
a
message
for
IE6
users
telling
them
to
 switch
browsers.



  • 8. What’s
the
problem?
I
want
to…
 •  Test
the
submission
of
the
form
with
invalid
data
 such
that
an
error
is
displayed
above
the
form
 with
client
side
validaCon
if
the
client
has
 JavaScript
and
server
side
validaCon
if
not
and
the
 form
is
above
the
content
on
the
web
page,
except
 for
IE6,
where
the
form
error
displays
below
the
 form.
for
Firefox,
Safari,
Opera,
and
IE7,
but
 display
a
message
for
IE6
users
telling
them
to
 switch
browsers
and
make
sure
*nix
users
get
a
 virtual
high‐five
when
they
submit
the
form.



  • 9. What’s
the
problem?
I
want
to…
 •  Make
sure
it
all
sCll
works
six
months
from
now
 when
I
forget
what
the
heck
this
form
was
 supposed
to
do.

  • 10. Take
a
look
at
Selenium.
 h'p://seleniumhq.org

  • 11. What
is
it
not?

  • 12. Selenium
Architecture
 •  Record
workflows
 •  Interact
with
content
displayed
in
the
browser
in
a
 fairly
robust
way
 •  Create
tests
from
workflows
in
the
language
of
 your
choice
 •  Same
test
code
can
be
browser
and
OS
agnosCc
 •  Built‐in
remote
control
and
grid
funcConality

  • 13. Selenium
IDE
 •  Firefox
Plugin
 •  Record
workflows
 •  Play
back
workflows
 •  Exchange
workflows
 •  A
good
starCng
point
for
test
code

  • 14. Best
PracCces

  • 15. High‐level
Best
PracCces
 •  The
IDE
generated
code
is
garbage,
but
you
fully
 expected
that.
:‐)
 •  Very
dependent
on
screen
scraping
 •  Very
dependent
on
element
nesCng
 •  SuscepCble
to
Cming
issues
 •  But
it’s
a
good
starCng
point
for
learning!
 •  (Brush
up
on
your
Xpath)

  • 16. Goals
for
Selenium
TesCng
 •  If
stuff
moves
around,
but
the
funcConality
is
 there,
the
test
should
not
break
nor
require
 modificaCon.
 •  If
content
is
changed,
but
the
funcConality
is
 there,
the
test
should
not
break
nor
require
 modificaCon.
 •  If
your
network
is
latent
or
your
computer
is
under
 load,
the
test
should
not
break.

  • 17. Use
Specific
DOM
IDs
 •  Trouble:
//div[@id='sidenav‐content']/table[1].0.2
 •  Less
trouble:
//div[@id=’bu;on_next’]

 •  Design
for
test
 •  ID
is
unlikely
to
change
(if
you
have
a
good
naming
 scheme!)
 •  Move
item
to
test
anywhere
on
page;
across
pages
 •  Easy
to
separate
“is
it
there?”
from
“does
it
 contain
what
I
expect
it
to?”

  • 18. Avoid
String
Matching
 •  Trouble
in
scraping
screen
for
string:

 An
error
occurred.
Sorry.
Tough
noogies.
 •  Less
trouble
in
checking
presence
of
element:
 //label[@for='username'
and
@class='error']
 •  Use
the
DOM
agributes
as
much
as
possible.
 •  Match
long
strings
as
ligle
as
possible.
 •  Best
kept
to
keywords…
does
element
contain:
 – “required”,
“order
failed”,
”error”


  • 19. Is
The
Page
Ready
To
Test?
 •  Built‐in
“is
page
done
loading”
method
less
than
 perfect.
 •  Look
for
something
on
the
page
 –  Header
 –  Footer
 –  Ajax
–
No
swirly
icon

  • 20. Go
Higher
Level
 •  Start
refactoring
into
higher
level
methods
sooner
 rather
than
later
 •  Common
ones:
 isPageReallyReady
 –  clickAndWait
 –  createNewAccount
 –  login
 –  assertBlahAndCaptureScreenshot
 –  populateFormAndAssertDataAppearsInDatabase
 – 
  • 21. Go
Higher
Level
 •  Organize
base
classes
around
workflows
 –  Why?
Common
test
fixtures!
 •  Common
fixtures:
 – Tests
requiring
an
account
 – Tests
requiring
no
account
 – Tests
requiring
signing
up
for
an
account
 – Tests
requiring
a
paid
for
item
 – Tests
requiring
data
to
display
that
is
difficult
to
 produce

  • 22. Make
Changes
Easy
 •  Organize
unit
test
classes/files
around
URIs
 •  Edge
case
tesCng
 •  Data
validaCon
 •  Logged
in
versus
logged
out

  • 23. Make
Changes
Easy
 •  Organize
funcConal
test
classes
around
workflows
 •  Create
an
account
(mulCple
steps)
 •  Buy
something
 •  RMA/cancel
something
 •  Provision
something
 •  Thing
1
interacts
with
Thing
2

  • 24. Plan
for
Failure
 •  Keep
unit,
regression,
funcConal,
and
verificaCon
 tests
separate
 •  Ideal
is
funcConal
test
failed,
and
a
unit
test
told
 you
exactly
what
caused
the
failure
 •  Or
a
funcConal
test
failed,
and
a
regression
test
 told
you
you’ve
seen
this
bug
before
 •  No
debugging
necessary

  • 25. Plan
for
Failure
 •  Keep
unit,
regression,
funcConal,
and
verificaCon
 tests
separate
 •  Shorten
Cme
between
failure
creaCon
and
failure
 discovery.
 •  Run
test
suites
at
different
frequencies/events.

  • 26. Avoid
Workflow
Overlap
 •  Do
as
much
setup
behind
the
scenes
as
possible
 – Create
an
account
in
the
database
rather
than
form
 – Add
an
order
item
in
the
database…
 – Etc.
 •  Aim
to
test
just
a
single
“thing”
per
test
case
 •  Refactor
prerequisite
workflows
to
base
classes

  • 27. Selenium
is
Slow
 •  Rare
to
have
a
test
case
execute
in
less
than
5‐10
 seconds.
 •  Clean
browser
for
each
test
case.
IsolaCon.
 – Human
Cme
more
valuable
than
machine
Cme.
 •  Plan
accordingly.
 •  Open
exasperated
by
external
dependencies
and
 systems…

  • 28. Mock
up!
Unplug!
 •  Everything
but
a
verificaCon
test
should
use
 mocking
 •  Mocking
 – Mock
behavior
of
external
system
in
a
fast
and
 reproducible
way
 – Example:
DynDNS.com
and
credit
card
processor
 – Be
able
to
reproduce
specific
error
responses!!!

 – Anyone
can
make
something
that
works
on
success.
 Our
job
is
to
make
it
work
on
parCal
failure.