Date post: | 13-May-2015 |
Category: |
Technology |
Upload: | rubytester-testrus |
View: | 1,860 times |
Download: | 2 times |
Semantic Test Objects in Ruby and Watir
Human Readable Machine Executable Test Case Design
for Web Applications
How
Does Traditional Testing Work?
Let’s make some assertions =>
Traditional Test Cases
Written in Language processed and executed by Human Beings who require specialized knowledge.
Traditional Test Case Notation
Documents as Pages of Text bound to specialized Formatting. Presentation
and data glued together.
Costly to Write. Slow to Execute
Requires Live Performance of a Skilled Tester. Each Replay is Another Live
Performance!Long Cycle Time$
TADA!Just Automate!
Record and Play it Back
It seems so easy, right?
(maintenance nightmare)
The Silver Bullet
What do you get when you automate Manual, Natural Language Step By Step Procedural Tests that only a
machine can read?
Yes, Let’s Automate. With Human Readable and
Machine Executable Notation
Semantic Functional Test Object Model
TestObject.message(subject)
Semantic Test Objects Notation
Human Readable Machine Executable
Unnecessary Text Out
• “By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems” – Alfred North Whitehead
• “While what is being discussed here is software development not notation sets, the same principle is operative if one thinks of a notation set as the ability to represent a problem to one's self.” – Dr. Pam Lawhead
http://john.cs.olemiss.edu/~lawhead/summary.html
OO dot Notation
Human Readable
Billy.clean(your_room) said Mom to her ChildRoom.clean_up() said Billy to his RoomObject.message(subject) said Object to Another
Machine Executable
Can be written in any OO Language.
Request, Response
• Object Oriented Notation captures the Interaction between Objects.– Every request gets a reponse
• When Mom sends a message to Billy does she get an answer?– Yes – but not what does the call to Billy return?
• Tests as Concrete Examples rather than Abstract Description
Understanding TestObject
• All ‘things’ in a TestCase are TestObjects.• All ‘steps’ in a TestCase are about sending
messages to TestObjects• All ‘things’ are derived from Domain Model,
UseCase Model, User Inteface Model• All ‘things’ live in Application Test Map, a kind of
Semantic Test Objects API for testing.
Separate Design from Implementation
• You’ve heard this before, right?– TestCases talk to TestObjects– TestObjects talk to the Browser– Abstraction Layer built from Business Domain Model
• Decouple and Glue instead• TestCases speak the language of the Test
Domain.• TestObjects speak the language of the browser,
IE, FireFox, Safari, Mobile, whichever….
TestCase Definition
• TestCase is an inventory of tests• Executed in context (TestScope)• Validating expected existence and expected
behavior of the System• Agreed by Customer• Resulting in pass or failure
Ruby
High Productivity. Object Oriented. No compile. Interpreted. Dynamically
Typed. Widely used
WatirWebAppTestingInRuby
Pronounced [water]
Ruby Library. Talks to IE DOM at runtime. Browser Automation Interface.
Document Object Model
Tests talk to DOM in memory. HTML + CSS + JavaScript + Ajax +
UserInteraction + ???Tests speak semantic structural DOM
App Test Model Interface
Construct new TestObject from API or build new ones
Abstract Business Domain Model
Tests > API > Browser
Semantic separation.
Tests talk to API Test Objects which are wired to speak to the DOM
‘manual’ vs ‘model’
• Process Based Testing• Linear step by step
snapshot based testing• Dependent on previous
run and individual implicit knowledge of the tester.
• Many lines of text written in author’s style.
• Deciphering meaning.• Abstract Description
• Object Based Testing• Non linear behavior and
state based. • Holographic view of
system. Context and Perspective
• Shared vocabulary. Standard Notation.
• Explicit expectations• Concrete Examples
Thank You
Questions?