Gauge and Taiko in Action

User Journey Testing
with Gauge and Taiko

Scott Davis
scott.davis@thoughtworks.com
@scottdavis99

Introducing Gauge, a framework for User Journey tests.

Presented by Scott Davis. His email address is scott.davis@thoughtworks.com. His Twitter handle is @scottdavis99.

Scott Davis' Biography

Hi! My name is Scott Davis. I'm currently a Principle Engineer with ThoughtWorks. Before that, I ran a software consultancy out of Denver, Colorado called ThirstyHead.

I've been writing about web development for years -- articles for IBM, books for O'Reilly and the Pragmatic Bookshelf, and most recently videos for O'Reilly as well.

https://gauge.org/

Gauge home page

Today, I'd like to talk to you about Gauge, a free and open source testing framework for acceptance testing.

But before we get too far, I think that it's worthwhile to define some terms more clearly. You'll hear me call acceptance testing "User Journey testing", which I think is a better description of what we're trying to accomplish when we use Gauge. Either way, this kind of testing is significantly different than the kind of testing that you probably do today, if you're a typical front-end developer.

https://taiko.dev

Taiko Homepage

Today I'd like to talk to you about Taiko -- a free and open source browser automation tool built by ThoughtWorks. So, what exactly is a browser automation tool?


is a test runner that makes it easy to express your tests in the language of your users.


is a browser automation tool that makes it easy to drive your web browser with a friendly Domain-Specific Language (DSL).

Together
Gauge and Taiko make writing User Journey tests easier than you might have thought possible.

User Journey Test

User Journey tests are written in the language of the end user, not in the language of the developer (either programming or spoken). Users typically say things like, "I'd like to add tomatoes to my shopping cart", not "I'd like to add the UPC string of the selected item to that array of strings over there in the Cart component."

Now, while literal-minded developers might scoff and think, "Meh, as long as the functionality gets tested, does the language of the test really matter?"

Here's the deal: it does. It really does, especially when we're talking about User Journey tests. You can call them "acceptance" tests, because what we're trying to figure out is what an "acceptable" website looks like to the user -- Is it acceptable if you can't add items to a cart? Is it acceptable if you can't check out and actually purchase the items?

So by calling these tests User Journey tests, it brings the user back into forefront the conversation. The tests are written in the user's language. The acceptance of the finished project is ultimately up to the user, not the developer.

Design Thinking starts with empathy.

If you ask a typical developer what step #1 of a new project is, chances are good that they'll say something like, "Pick a web framework" or "Set up a new code repository".

If you ask a fan of Design Thinking what step #1 of a new project is, they'll say, "Empathy". Putting yourself in the mindset of the user. Understanding what they want to accomplish when they use your app.

Because if you start writing tests in the language of the user, it helps you think like a user. And then, it opens up creativity in an entirely different part of your brain. "Hmmm, if I buy tomatoes every week, wouldn't it be cool if I could just re-purchase last week's shopping cart full of the food I normally buy?" "I'm already uploading a pre-written shopping list to my cart for my automated unit tests -- I wonder if it would make my users lives easier if they could do the same thing?"

Cucumber History

Cucumber Example

Cucumber Example

Gauge Scenarios

Gauge Implementations

Gauge Report

Gauge Installation

Gauge New Project

Gauge Run

https://taiko.dev

Taiko Homepage

Today I'd like to talk to you about Taiko -- a free and open source browser automation tool built by ThoughtWorks. So, what exactly is a browser automation tool?

Selenium History

As a matter of fact, ThoughtWorks has been actively working on browser automation tools for over 15 years at this point.

You might be familiar with "Selenium", a free and open source browser automation tool that we released way back in 2004.

Simon Stewart released a free and open source tool called "WebDriver" back in 2007, and the two projects merged in 2009.

Selenium Flaky

Taiko includes Chromium

Chromium

What makes Taiko so stable is that it ships with a known-good, compatible, working release of Chromium when you 'npm install' it.

And what is Chromium? Well, outside of software, it's the element used to make the chrome features on your car. In the web development world, it's the free and open source core that Google uses to make their Chrome browser. (Clever, eh?)

But Chromium is also at the core of the Opera browser. And in a recent, unexpected move, Microsoft abandoned nearly 30 years of building their own web technologies to make Chromium the core of their Microsoft Edge browser.

So while there are still healthy competitors to Chromium in the open source ecosystem -- Firefox uses a core called Gecko, and Apple's Safari uses a core called WebKit -- Chromium is a popular, well-supported foundation to many popular web browsers that you and your users are most likely already using.

Chrome DevTools Protocol

Since the new WebDriver W3C standard isn't fully implemented across all browsers today, Taiko uses the next best thing: the Chrome DevTools Protocol.

As you might've guessed from the name, this is the same stable low-level protocol that the Chrome Developer Tools use to interact with the browser, like the JavaScript console. If you've ever run a Lighthouse Audit on your website, Lighthouse uses the Chrome DevTools Protocol to pull performance metrics and accessibility results to build out its detailed analytics reports.

Taiko has access to all of the same data and browser automation capabilities that these familiar development tools have. And now you do, too, in an easy scriptable environment.

Taiko REPL


$ taiko


Version: 0.5.0 (Chromium:73.0.3638.0)
Type .api for help and .exit to quit

>

If you've already installed Taiko, you can simply type 'taiko' at the command prompt. This will launch you into the interactive REPL where you can explore the features of Taiko at your own pace.

At this point, you are given two suggestions to type. One of these suggestions will make this a very short discussion. Why don't you type '.api' instead and see what other commands are available to you? 


> .api

Browser actions
    openBrowser, closeBrowser, client, switchTo, 
    setViewPort, openTab, closeTab

Page actions
    goto, reload, title, click, doubleClick, rightClick

[snip]

Run `.api <name>` for more info on a specific function. 
    For Example: `.api click`.
Complete documentation is available at 
    http://taiko.dev.

Typing '.api' brings up a list of all of the Taiko commands.

These should be fairly straight forward to understand. The 'openBrowser' and 'closeBrowser' commands do what you'd expect them to do. 'openTab', 'closeTab', 'click', 'doubleClick', 'rightClick' -- you get the idea.

But if you want to learn more about any of these specific commands, simply type '.api' and command name to pull up more information. 


> .api openBrowser

Launches a browser with a tab. The browser will be closed 
    when the parent node.js process is closed.

Example:
	openBrowser()
	openBrowser({ headless: false })
	openBrowser({args:['--window-size=1440,900']})
	openBrowser({args: [
	      '--disable-gpu',
	      '--disable-dev-shm-usage',
	      '--disable-setuid-sandbox',
	      '--no-first-run',
	      '--no-sandbox',
	      '--no-zygote']}) - These are recommended args 
               that have to be passed when running in docker

For example, type '.api openBrowser'. Not surprisingly, this is how you open a new Chromium instance. But there are a number of flags that you can pass to control or customize your new Chromium instance.

When you're in the Taiko REPL, typing 'openBrowser' without any options will open a visible instance of Chromium so that you can see what you're doing. But if you're running Taiko as a part of your Continuous Delivery pipeline, you'll almost certainly want to run it in headless mode, which means nothing visible will be displayed. You can also control the size of the window, visible or not, to more closely emulate smartphone, tablet, or laptop users.

All of these are standard, out-of-the-box, Chromium flags. 


> openBrowser()

 ✔ Browser opened
A blank Chromium window

So, if you type 'openBrowser()' right now in your Taiko REPL, you should see a new instance of Chromium pop up with a blank tab, just waiting for you to do something interesting.

Demo

https://thirstyhead.com/conferenceworks

ConferenceWorks

https://github.com/ThirstyHead/
conferenceworks-tests

ConferenceWorks

Conclusion

So, what have we learned?


is a test runner that makes it easy to express your tests in the language of your users.


is a browser automation tool that makes it easy to drive your web browser with a friendly Domain-Specific Language (DSL).

Together
Gauge and Taiko make writing User Journey tests easier than you might have thought possible.

User Journey Testing
with Gauge and Taiko

Scott Davis
scott.davis@thoughtworks.com
@scottdavis99

Introducing Gauge, a framework for User Journey tests.

Presented by Scott Davis. His email address is scott.davis@thoughtworks.com. His Twitter handle is @scottdavis99.