Last week was my 1 year wedding anniversary (Yes I’m taken, sorry). Part of the wedding tradition here in the U.S. is eating the top layer of the wedding cake. It wasn’t half bad.

It got me thinking about the different layers of an automation framework.

I’m a little weird like that.

Automation Framework Layers

Don’t know about you, but I like to build frameworks that are less like onions & more like cake

Shrek: [peels an onion] NO! Layers. Onions have layers. Ogres have layers… You get it? We both have layers. [walks off]
Donkey: Oh, you both have LAYERS. Oh. You know, not everybody like onions. CAKE! Everybody loves cake! Cakes have layers!

The last thing you want is for a friend to peel back your automation code and start to tear up.

Quick disclaimer: There are many ways to “skin a cat”. Not saying this is the best way, Not saying this is the only way. This is just the approach picked up from others, and what I’ve done in the past.

The General rule of layering is that each section only touches the one below it. The same is true in automation.

General Layers

The bird’s-eye view of a UI testing framework.

• Test (A unit testing framework – Junit, Nunit, TestNG, etc)
• Framework (Automation code)
• Selenium (API for controlling the browser)
• Browser (Our App under test)

Next let’s cut a slice of the Framework layer and check it out.

Framework Layers

A piece of the pie

• Workflows (Common scenarios across multiple pages)
• Pages (Specific pages of the app)
• Navigation/UI Utilities (Common domain elements)

When writing Automation Framework I like to use a Page Object Pattern because it helps clearly model the functionality of the application.

We could cut any of these layers into smaller components. This is something I’m planning to do in the future. Until then hope your layers stay sweet.