Geb best practices at Greach 2017

30th May 2017
Marcin Erdmann

I have been involved with Geb, the open source browser automation solution, since mid-2011.  Geb is used on top of Selenium as an automated testing solution, and can also be used for scripting, scraping and other browser-based tasks that need automation.  I became the Geb Lead in 2014, and although I always wanted to do a conference talk about it I never succeeded at getting one accepted.  

During software conferences, like Greach, the Groovy Spanish Conference in Madrid, a significant percentage of talks are gentle introductions to tools in the ecosystem the conference is about. This is very useful for the attendees when the tool in question is fairly new and there’s a high chance that people will not know about it yet. That was the case with Tomas Lin’s Geb talk at Groovy & Grails Exchange 2010, which introduced me to it.

As Geb has been around for almost 7 years (the first public version was uploaded to Maven Central in August 2010) and reached version 1.0 in October last year, I felt that doing an introductory talk would not be useful. So I submitted “Geb best practices” for the 2017 edition of Greach.  

The goal was to share some of the best practices I’d developed while working on and using Geb for the last 6 years. I knew that not everybody would have the necessary experience to get the most out of such a deep dive, but I hoped enough people would find it useful. (If you are reading this and need something to get you started with Geb, then have a look at the Book of Geb.)

The item I wanted to share the most was how to become even more efficient when developing Geb tests. I do this by strongly typing Geb code to enable autocompletion and refactoring in the IDE.  In the presentation I explain which Geb constructs are understood by IntelliJ out of the box, and how to structure your code so that IntelliJ can understand all of it. I believe that being able to seamlessly navigate around your Geb codebase in IntelliJ makes it so much easier to understand the code, especially if it was written by another team member, or you’re coming back to it after a while.

I also explain:

  • what the benefits of properly structuring your Geb code into Modules and Pages are
  • how to benefit from Modules being Navigators and Navigators being Iterable
  • a couple of ‘tricks’ that became available in recent versions of Geb
  • when to use waitFor {} and why you don’t want to do it inline in your tests
  • why you want to spend time building up a set of fixture builders for your functional tests

I hope the talk at Greach was beneficial, and if you’re interested you can check out the slides and the video of the talk below.  

Energized Work’s other blog posts on testing.

No comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Web Analytics