Web Browser Automation Using Geb


5 Νοε 2013 (πριν από 4 χρόνια και 6 μήνες)

103 εμφανίσεις

Web Browser Automation Using Geb

Kyle Rogahn

University of Wisconsin


Computer Science

Computer Technology


Geb is a fairly new web browser automation tool that is very useful in certain web
application development projects.
It is a
like content selector and a WebDriver
automation tool wrapped i
nto one unique language. Using G
eb requires a few moving

parts but if
you require very extensive, in depth web application testing it can be extremely advantageous. It
can also be very useful in


smaller projects as well if you find yourself constantly clicking
through the same pages and scenarios to test certain web application functions.

Geb is currently
not even at version 1.0 but it is increasing in popularity due to its usefulness.

In the nar
rative that
follows you


when G
eb should be used,

what G
eb is, what it looks like, and
see some
examples of Geb code fragments.

Automating the Browser

The reasons may seem slightly obvious why having a tool to automate a web browser
would be
beneficial but all web application projects are not created equal. There are situations
where using Geb would save a large

amount of time (in the case of

software engineering


it would save a large amount of money too) and there are cases where
using Geb would
cost more than it would be worth. What are these scenarios?
To find out what these
scenarios are one needs to know

advantages and disadvantages of

a browser

automation tool

into a project



When to use Geb

The main advantage of
having a browser automation tool is to eliminate the need for
tedious manual testing. You would want to use a browser automation tool on a large project with
many test cases. Quality Assurance teams on big projects like this will have

thousands of test
cases to go through before a project is ready for deployment. With modern web applications they
can be very complex and just having j
unit tests running in your back end code is not enough to
catch errors. Once the back end code is integ
rated with the front end interface there can be many
errors that arise

when all the parts actually come together.

With complex applications like this it

forces the quality assurance teams to have to test a lot of the front end functionality by hand.

This b
ecomes very difficult the more complex the application actually is.



take an industry standard e
commerce application as an example. There are many
parts. First there is back end java code that handles the functionality of the application. Within
s code there

multiple layers needed to make the application robust and effective. This
depends on the design pattern that is used however let just use the MVC pattern as an example.
MVC stands for model, view, and controller. When using this design pat
tern one must define a
model, view, and controller for each feature that supports functionality on the user interface.
Then once
the model, view, and controller pieces all work together to support the new feature

the component that uses the feature must a
ctually be added onto the user interface. This is done
using some kind of markup language or template language in a web application. Once in use
some components will even need to talk to a database to get the required information they need
to function; for

example, if a custom
er scans a promotional code
the application
would need

access the database to receive that code, put it in the right text field and apply the correct
discount to the current total. To make a long story short this is a lot of moving
parts. Anyone
who has studied just a little bit of computer science can see that there is a lot of potential for bugs
in code of this complexity.

With complex code

comes a
large amount

. Using Geb to automate
certain tests can really
save time.

A scenario

that would be advantageous to use automation on
a one

that involve

navigation through many pages and a large amount of data entry. Say your
application requires a user to enter a large amount of personal information before they ca
n move
on to the next page of an application and you need to test one

feature three

pages deeper
into the application.

How would Geb help with this?

Geb you can write a test suite that will access all of the text fields and drop down
boxes and

enter in all of the information very quickly. You only have to define the information
you want in this boxes once in the Geb code. From then on they act like constants and you can
write the program to insert those constants in whatever field you see fit.
Once you enter in all the
necessary information you can then advance to the next page and so on and so forth until you get
to the feature you actually want to test. The difference in speed is exponential. To do the same
by hand it would take at lea
st five

minutes while Geb can do it in seconds. This is the
main advantage
using Geb.
Quality assurance teams could eliminate a lot of tedious testing time
and focus their time on testing the actual functionality
instead of mainly

performing data entry.

other main advantage is that it is not too hard to learn. The language is very readable
and the constructs do what they say they are going t
o do. For example the keyword “t
o” is
supposed to be followed by the name (if you have defined the page in your code
) or the url of the
page you want to go to (such as “GoogleHomePage”) so

a line of code using the “to” keyword
would read “t
o GoogleHomePage.”


As you can see it is very readable and simple to
understand. Most of the constructs in Geb read similar to th
is making the language something
that programmers can easily pick up. I will go more into

actual features of Geb code later on.


When to not use Geb

Geb’s usefulness takes a hit on smaller projects. When your web application does not
layers of pages and many forms that require data entry you may find Geb actually costs you
more time than it saves. Although you could still set up Geb to work with a smaller project it
may take more time

installing it,

learning it, and coding a Geb test f
or every


piece of

functionality that is added when a quick manual test would
. As you can see it really


depends on the project at hand. There is no cut and dried project size threshold

but since Geb is
fairly new and unknown it can be a bigger
risk to integrate it into a small project. If Geb doesn’t
save a lot of time it is really not worth taking the time to become familiar with because that time
would increase the cost on the project.

Another disadvantage of using Geb is

it is very picky abo
ut what environment your
website application uses
Geb needs to be



into a specific environment

to be
able to work. If you are already using some of these things in your project th


can be
installed in a few minutes
, otherwise it
could be very tough
Geb interacts with specific web
development environments like Grails, Maven, and Gradle. If your project does not use

at least
one of

these in the first place it is probably not a good fit for Geb. It

seems it

would take a

t of work to switch over the environment to one of the ones
I previously spoke about
; the
cost would be too great to even be worth trying to use Geb. However if your project uses these
environments than Ge
b would probably be a great fit to use in your web
application’s testing

The last main disadvantage of Geb is the guaranteed learning curve. Since Geb is so new
and unfamiliar to many programmers the
re is an almost certainty that newly integrating it into
your project is going to require extra t
ime for developers to learn. The up side is that Geb is
fairly easy to learn once you commit to learning it but it is still going to take time away from
other tasks to learn just like any other new language. Sometimes project teams are on such a tight

crunch that they

afford a few days to
learn and integrate a new language into their
project. However it would be worth those few days if you are spending more time on testing than
Geb could save you in the end. Usage all comes down to software engi
neering management
decisions and those are made differently on a project to project basis.

What actually is Geb?

As I have previously described Geb is a browser automation solution. This means Geb
can completely take control of your web browser and progra
mmatically perform tasks that you
would otherwise have to perf
m manually
. As you can see this would be extremely useful for
testing web applications. Now that I have previously described the advantages and disadvantages
I will get more into the bare
s of Geb. Geb’s features are based on combining f
eatures from
WebDriver, JQuery
, and the Groovy




WebDriver is the main driving force behind Geb.

The WebDriver integration is

handles the browser automation.
WebDriver has the capability to modify document
object model content on a web page

. Document Object Model (DOM) content is the specific
interface components on a website. These are things like text fields, buttons…etc. This means
that WebDriver can do
things like insert text into a text field, since a text field is a DOM

WebDriver can also control the behavior of a web browser. You may be thinking why

use Geb

if WebDriver can do its own version of browser automation and DOM

The main reason is the readability and simplicity. As you will soon see Geb is a lot
more readable and easy to

than just using WebDriver itself. Geb takes its main


functionality from WebDriver

but combines it with other tools that make it s
impler. Below is
some java code


using Web
river to perform a


(see F
igure 1).
Although it is not extremely complicated writing a WebDriver test it is still more work than
writing a Geb test be
cause Geb uses the language of G
roovy which saves a lot of key strokes and
is easier to read and understand.

A Very Groovy Language

Geb speaks in the language of Groovy. Groovy is a dynamic programming language for
the java
virtual machine. Although some consider Java to be a dynamic language Groovy behaves like
traditional dynamic languages that programmers are used to like Ruby, Python, and Smalltalk

. Basically Groovy builds upon the strong features of Java but

adds features that one would
expect in dynamic languages like Ruby. One of the biggest advantages Groovy has is its
readability and low learning curve. It also integrates easily with virtually every Java library

Another advantage is that it simplifie
s testing because of its support for mocking and unit testing.
This is why Geb uses groovy as the language of choice. See Figure 2 below for some basic
groovy code.

: Google Search Using Webdriver


As you can see


groovy is
very similar to Ruby. Geb tests are written using this
language and this allows for use of some unique testing keywords that really make testing simple
and readable. But before I actually go into how to write a Geb test it is important to know t
final piece Geb uses in its implementation: JQuery.


JQuery in a nutshell is basically a content selector. Its purpose in Geb is to improve on
the DOM content selection model of WebDriver to make Geb a more powerful browser
automation tool. When
automating a web browser a very important step is being able to quickly
and easily locate content on the page that the automation tool will either use or modify. JQuery’s
purpose is to provide that


selection feature. JQuery is a JavaScript library

that can
actually go into the html code and
modify or find desired components. It is also able to handle
events and provide its support for all the major browsers (IE, Firefox, Safari, Chrome…etc)

Using JQuery with Geb makes the browser automation fa
ster. Some of its language even makes
its way into the syntax of Geb. This is why it is important to know.

Consult figure three below to see a basic use of JQuery. In this example JQuery is being
used to prevent a link embedded in the html code of a websit
e from working. Lines 11 through
16 on
Figure 3

is actual JQuery code embedded into the html code. What this code does is
overwrite the click event on the link defined in line 8 preventing it from taking the user to
jquery.com. Geb uses JQuery to make mod
ifications to web pages in a similar matter.

: Groovy Code Example


: JQuery Example

Knowing the pieces of Geb are important before getting into using it because it makes it
even easier to learn when you start realizing what pieces are
being used where. WebDriver,
Groovy, and JQuery all play an integral part in making Geb a powerful browser automation tool.
Now that you have a background in the main pieces of Geb we can get into some examples and
explanations of how Geb works.



Geb can be combined with many testing frameworks all outlined in
The Book of Geb

it can be found on the Geb website


one needs to see

what Geb looks lik
by itself (without importing any fra

After knowing what Geb looks like by itself one
can see
what a typical test looks like using the Spock framework.


framework is
included in the Geb package so a simple
“import geb.spock.GebSpec” in your code should take
care of the
entire configuration.

It is not something that requires a large amount of explaining but
I will point out when the Spock framework is being used in following examples.

It is
recommended to use this framework when using Geb because you can write the most “c
concise, and easy to understand test specifications with little effort”



s now dive into to a simple Geb example. Recall the WebDriver Google search
example from
Figure 1
. Next you will see a

Google searc
h example in Geb and

it will be


with WebDriver. The following Geb co
de is an inline scripting style;
it doesn’t use
any predefined
packages or frameworks
, it just uses basic Geb

In the following example
computer is
going to go to Google,
enter Wikipedia in the search field, and eventually click the
link to Wikipedia and go to the page.

Notice how all you need to do to go to the webpage is use the keyword “go” (line 4)
followed by the
. In the case of WebDriver implementation you need to

do a “driver.get()”
with the url as the parameter. Geb’s version of this implementation is a lot simpler and easier to
remember. You do not have to look through the methods of the driver to fig
ure out which one
goes to a url;

you just need to remember the

one word: “go.”
Also notice how you can do an
“assert” statement without defining any testing frameworks. This makes it very easy to
check if
you actually got to the right page. To do the same operation in WebDriver you would need to do
a “driver.getTitle
” and compare that string using the java “.equals” method. Geb simplifies
WebDriver but is still able to keep the powerful functionality.

A third and final note about the above example is the lines that use the “$”. This is where
JQuery comes in. If you r
ecall the example from figure three this is how JQuery accesses content
on the webpage. Geb uses that notation as well.
It is able to find “q” which is the variable name
for the text field
on the Google home page and enter text into it all in one line. In
our pure
WebDriver example from figure one this process takes two lines to perform. You need to find
Figure 4: Google search using Geb


the element then use “sendKeys” to programmatically type in what you want.

As you can see

requires less coding

than just using WebDriver straight up

age Object Model

inline Geb programs are built on the page object model. Using this model is the
preferred way to use Geb. If you need to write a quick test you can certainly use the inline style
as shown in
igure 4 but using the Page Object Model
makes your tests more readable and can
save you time in future phases of your project. The page object model in a nutshell is based on
defining page objects in the test code and reusing them whenever you need to refer to that page

If this mo

was used on the example in F
igure 4 the programmer would not have to
use the JQuery notation in the script; the programmer could simply call the pre
defined page

To do this you woul
d define a page object in

your G
eb code. Inside of that specific page
object class you would define all of the content on that page so you could easily refer to it later
without having to use JQuery and look up the variable names of the desired content on the page
you are working
To do this you use the JQuery

character ($)

but store the result in a
class variable that you can call when you are doing work with that specific page. Let

s look at
what a typical page
class looks like (see F
igure 5 below).

Figure 5, above, i
s how you would represent a login page using the page object model. It
is very simple: name the page
, specify its url and content, d
efine the content by using the J
notation to access the object on the web page but name it something meaningful so your

code is
very readable. Once you define your page you can refer to it as, for example, LoginPage
anywhere in your code. Notice how t
he last line of actual code on F
igure 5 actual

refers to
another page (AdminPage) since it needs to interact with that pag
e as well. If you did not have
AdminPage defined you would need to put in the url or use JQuery to find it. Geb’s
implementation of the page object model is really what defines it and makes it more powerful
than other browser automation tools. Let’s dive i
n a little further to see what a test script using
the page object model looks like.

Figure 5: Page Object Model Example



Seeing an example of a test using the page object model really brings everything
WebDriver functionality is used in automation, JQuery is used in defin
ing the content
in page object model classes, Groovy provides the language support to cod


page objects,

is the testing framework we are going to import. Below is a test specification for the
login page
we defined above in F
igure 5.


6: Geb Test Using Spock Framework and P
age Object Model

The first thing to do when writing a test spec for a page is to use the def keyword to
define the name of the test. In this case we are calling it “login to admin section.” You want to
name tests ver
y specifically to increase maintainability and readability. First what the test is
going to do is try

to go to the login page. If
for some reason


cannot go there the test will be
reported as failed due to the “given:” keyword.
This will only go on if
the browser is at the login
page after the instruction is completed. The next instruction is going to add text to the user name
and password text fields using the “with” method which will modify the state of the content on
the page to whatever is specified

(in this case we are adding text for username and password)
Right after the state of the page is modified to include the information in the username and
password fields

the test will then click the login button programmatically. Once this action is
leted then it tests to see if the browser is “at” the
admin page
. Since the


returns a Boolean

it will decide whether or not the test passed due to the state o
f the browser. If


it is at the a


then everything is good and the test wil
l be shown as passing, otherwise it
will be reported as failed.

Concluding Statements

As you can see from the explanation of the test (figure 6)

in the previous section,
Geb code

very reada
ble. This is why Geb is so powerful; it is easy to write, easy
to learn, easy to modify,
and it works! There are a few moving parts to get it going

but if it is right for whatever project
you may be doing it can save a large amount of time and provide much more accurate test
coverage. Using the page object model effi
ciently makes for simple test specifications that can
cover a large amount of test cases. Defining all of the pages in your web application using the
page object model can really make it easy to go from page to page in testing since all you have to
say i
something along the lines of

“to LoginPage.” Also, using the browser automation
techniques can save a large amount of time because you don’t have to keep doing data entry into
text fields every time you want something to be tested. Type the information onc
e in a test spec
and then you can run it as many times as you need.

If you decide that
Geb is right for your

ore information on how to configure Geb in a project and further documentation can be
found at

have had some experience using Geb and

would highly recommend

for in depth web application testing.




very groovy browser automation… web testing, screen scraping and more
. (n.d.).

Retrieved from

Getting started with webdriver
. (n.d.). Retrieved from

Gradle documentation
. (n.d.). Retrieved from


a dynamic language for the java platform
. (n.d.).

Retrieved from

How jquery works
. (n.d.). Retrieved from

Ledbrook, P. (2010, Aug 28).

The future of functional web testing?
. Retrieved from

Page objects
. (n.d.). Retrieved from

automation for web applications
. (2012, Dec 20). Retrieved from