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?