Automation Strategy: Flow vs Page Objects Part 1 - or - If You Think Page Objects are Enough, Think Harder

Motivation

The Page Object Model (POM) has been the de facto standard in UI automation using Selenium for years now.  Here* is a typical primer on the subject.  This primer does a perfectly reasonable job of showing how people normally use POM, and it also clearly shows the reason that using POM the way I've seen a lot of people use it is insufficient for writing maintainable tests.

The problem is illuminated in the author's 5th reason for using POM: "Any change in UI can easily be implemented, updated and maintained into the Page Objects and Classes."  If you've done this for a while, you'll notice what is not said here - that a change in business process or higher-level user interaction with the site cannot be easily implemented in our automation.  For that type of change, if we were to only use POM, we'd have to update all of the related tests. That is to say, this style of POM is sufficient for encapsulation and maintainability of UI elements and structure, but we need something higher-level to encapsulate and maintain business processes.

Typical POM

As a trivial example, let's say you have this PO class and test:

	class LoginPage
	element username = driver.webElement(:id, "userName")
	element password = driver.webElement(:id, "password")
	element loginButton = driver.webElement(:id, "submit")
	method loginTest
	driver.goto("http://www.myapp.com")
	loginPage.username.set("josh")
	loginPage.password.set("p@ssw0rd")
	loginPage.loginButton.click()
	assertTrue(homePage.menu.exists(), "Error: we're not on the home page")

view raw flows01.cs hosted with ❤ by GitHub

You're going to have hundreds of other tests that contain this same login code of course.  What happens when the id of the username field changes?  With POM, you're golden.  You just update the username element on your LoginPage class.  But what happens when there's a new step in logging in?  Now all of your tests have to change to look like:

	void loginTest
	driver.goto("http://www.myapp.com")
	loginPage.username.set("josh")
	loginPage.password.set("p@ssw0rd")
	loginPage.acceptTermsAndConditionsCheckbox.check() // new line
	loginPage.loginButton.click()
	assertTrue(homePage.menu.exists(), "Error: we're not on the home page")

view raw flows02.cs hosted with ❤ by GitHub

As an automation developer, you can be certain that your site will change - and not just in rearrangement or renaming elements on a page. Some people will say "Hey, I've got a method called login() in my LoginPage class, so that's all I'll have to update." Well kudos, you're a big step closer, let's check it out. We have the login() method to our LoginPage class, so all we do is add the element and the line in the login() method. While we're at it, we'll put the goto() in there. That way our test will be super clean and maintainable:

	class LoginPage
	element username = driver.webElement(:id, "userName")
	element password = driver.webElement(:id, "password")
	element loginButton = driver.webElement(:id, "submit")
	element acceptTermsAndConditionsCheckbox = driver.webElement(:id, "acceptTOC") // new line
	void login(uname, pwd)
	driver.goto("http://www.myapp.com")
	username.set(uname)
	password.set(pwd)
	acceptTermsAndConditionsCheckbox.check() // new line
	loginButton.click()
	void loginTest
	loginPage.login("josh", "p@ssw0rd")
	assertTrue(homePage.menu.exists(), "Error: we're not on the home page")

view raw flows03.cs hosted with ❤ by GitHub

You will be good to go for this trivial example. But what about when your company decides to change a business process in your app? Let's say you want to add a step in a checkout process such as buying a couch. In the past, you had the code below... you were smart so you even wrapped clicking submitButton with a method, not wanting to mix the use of PO methods like loginPage.login() and use of the PO elements themselves like loginPage.submitButton.click():

	class optionsPage
	// page element definitions...
	void selectOptions(color, leatherTrim)
	case color:
	"red": redColorRadio.click()
	"blue": blueColorRadio.click()
	"green": greenColorRadio.click()
	if (leatherTrim)
	leatherTrimOptionCheckbox.check()
	void clickSubmit()
	submitButton.click()
	class paymentPage
	// page element definitions...
	void enterPaymentDetails(ccNummber, ccExpiration, ...)
	//...
	void clickSubmit()
	submitButton.click()
	void validateSale()
	assertTrue(confirmationMessage.text == "Thanks for your order", "Error: sale not confirmed")
	void checkoutTest
	loginPage.login("josh", "p@ssw0rd")
	// select a couch to buy...
	optionsPage.goto()
	optionsPage.selectOptions("red", false)
	optionsPage.clickSubmit()
	paymentPage.enterPaymentDetails("4312432143214321", "09/2022", ...)
	paymentPage.clickSubmit()
	paymentPage.validateSale()

view raw flows04.cs hosted with ❤ by GitHub

The Issue...

The problem is that we're still modeling the interaction with the UI - we're focused on the website. What we should be modeling is what the user wants to do. The user doesn't want to select from a dropdown on pageA and click some buttons on pageB, they're trying to buy a couch, and we're not encapsulating that anywhere, except arguably in the test. That's too late, because we're going to have dozens of really similar tests where the user just wants to do a tiny thing different, such as choosing express shipping vs. regular shipping, so all that test code is going to be duplicated, and we're not going to be DRY at all.

In this example our app changed, and now we have an "assembly and delivery" step. All our tests have to change again:

	void checkoutTest
	loginPage.login("josh", "p@ssw0rd")
	optionsPage.goto()
	optionsPage.selectOptions("red", false)
	optionsPage.clickSubmit()
	assemblyPage.selectAssemblyAndDelivery(true, "express") // new line
	assemblyPage.clickSubmit() // new line
	paymentPage.enterPaymentDetails(4312432143214321, "09/2022", ...)
	paymentPage.clickSubmit()
	paymentPage.validateSale()

view raw flows05.cs hosted with ❤ by GitHub

Flow classes

The Flow class is intended to do this encapsulation and abstraction for us.  It models what the user is trying to accomplish (user stories?) when they're using your application.  Let's check it out:

	class LoginFlow
	LoginPage loginPage
	login(uname, pwd)
	loginPage.login(uname, pwd)
	class BuyFlow
	OptionsPage optionsPage
	AssemblyPage assemblyPage
	PaymentPage paymentPage
	buyItem(color, woodTrim, assembly, deliveryType, ccNum, ccExpiration, ...)
	optionsPage.goto()
	optionsPage.selectOptions(color, woodTrim)
	optionsPage.clickSubmit()
	assemblyPage.selectAssemblyAndDelivery(assembly, deliveryType)
	assemblyPage.clickSubmit()
	paymentPage.enterPaymentDetails(ccNum, ccExpiration, ...)
	paymentPage.clickSubmit()
	validateSale()
	paymentPage.validateSale()

view raw flows06.cs hosted with ❤ by GitHub

And now your tests can model the use cases, and they simply looks like:

	void checkoutTest
	loginFlow.login("josh", "p@ssw0rd")
	buyFlow.buyItem("red", true, false, "express", 4132443212343241, "09/2022", ...)
	buyFlow.validateSale()

view raw flows07.cs hosted with ❤ by GitHub

So maybe the title of this post shouldn't be Flow vs Page Objects, because both layers are useful and work together. The POs encapsulate the UI, and the Flow encapsulates the business rules. Then the tests simply encapsulate the use cases. Honestly, if your app is small enough, like a mobile app, you can do both in the Flow class. I've done this successfully, but a UI refactor probably would have cost me more than if I'd done a proper PO layer.

Looking at the test case, you probably see the potential problems:

1. The more work we make our methods do, the more data we have to pass in to let them know how to do it. For this, we'll have to start consolidating data elements into their logical groups. I'll talk about that in the next post here.
2. Using flows works great for positive tests, but what about negative tests?  I'll talk about that in this post.

Continue...

The next post in this series is Automation Strategy: Flow vs Page Objects Part 2

*In case the site I referenced is deleted, here is a webArchive of it

Automation Strategy: Cucumber for Testing - You're (Very Possibly) Doing it Wrong

Potential Issues

The first time I worked on test automation was around 2006, and when I started seeing people using Cucumber I didn't get it.  I always thought there were a lot of problems with thinking that a human-readable English DSL (domain-specific language) was going to solve your problems.  The most immediate one was that English doesn't compile.  Enter Step Definitions, which take a lot of time to write, translating the English to the method calls in your code.  In addition, having everyone agree on the exact syntax of the Gherkin seemed like a huge challenge.  For the simplest case of being logged in, is it "Given I am logged in" or "Given I'm already logged in" or "Given I have logged in?"  All of this just to have tests written in English... no way.

Flows

I have been using Flows in addition to or instead of Page Objects in my frameworks for years, and I wanted to show someone a side-by-side comparison of my Flow methods calls vs Gherkin.  Here's the example from a test a few companies ago.  This (flow code) is actual code from the test.

Gherkin	Using Flows
Given a user is logged in	flow.login(user01)
When a user adds a pen to the cart	flow.add_to_cart(pen)
And the user checks out	checkout_total = flow.checkout()
Then the receipt is viewable	flow.verify_receipt_exists()
And the cart is empty	flow.verify_cart_is_empty()
And the receipt total equals the order total	flow.verify_receipt_total_equals(checkout_total)

The beauty of having this flow class is that with a decent IDE, you type "flow." and you'll be given a list of all the methods in the class, which is easier than remembering the exact Gherkin phrase.

I had been having these thoughts for a while.  I have never seen people using Cucumber but always wanted to.  Some people I know and respect say it's useful or that they've seen it done.  Then I saw this post* by Aslak Hellesøy, the author of Cucumber, and was so happy to have my beliefs confirmed.  It's a quick read, but basically he says if you're just using Cucumber for automated testing, you're missing the point.

Cucumber is a BDD tool, and the automated tests are a byproduct of the process.  If the testing team is the ones "doing Cucumber" you likely need to reevaluate your situation.  Using Cucumber correctly involves buy-in from product and development as well as QA.

For more on Flow vs Page Object, check our my post here.

*web archive of Aslak's post

Information Science: Visualizing x^4 and Higher Powers

Someone online asked "We can imagine x^2 as a square and x^3 as a cube. How can we imagine x^4 and other high powers?" and I had considered this thought experiment in college working with multidimensional arrays.  Many people get hung up thinking about physical dimensions of height, width, length and fail to realize that many attributes of an object or system can be considered a dimension.  So here's my answer:

Hopefully it's clear the upper left (of the 9) boxes is your first cube.  Then you can see you have arrays and eventually cubes of cubes (x^6). 

This works well for data representation, at least to x^5.  For example let's take x^4, and let our dimensions be length, width, height, and time:

We can see the length, width, and height at each point in time.  The object we're representing is getting smaller as time progresses.  Maybe it's an ice cube.

Maybe in the x^5 scenario, our 5th dimension could be temperature, so the top row could be some "medium temperature," the middle row could be "very hot" and the bottom could be "very cold" so the ice cube doesn't melt at all:

If you are working in higher order math, being able to visualize (and hopefully the need to visualize) goes out the window pretty quickly.