Geb Gems: Using Pages and Modules

Posted on April 30, 2015 by Albert van Veen

In the previous blog post about Geb, we have been introduced to the Geb Framework. In this blogpost we will be introduced to Pages and Modules. A Page represents a specific page from a web application. A module represent a part of the page; for example a sign-up form, a menu bar or contact form. Pages and Modules are very useful since they are very easy to reuse and therefore useful to create more advanced UI tests.

In this blogpost we are going to use Pages and Modules to test the contact form of the JDriven website. We will verify that a success message will appear if we submit a valid form.

Pages have a url attribute which represent the address to the page. To get the complete url, Geb requires a baseUrl which we can define in the GebConfig.groovy

baseUrl = "http://www.jdriven.com/"

1	baseUrl = "http://www.jdriven.com/"

Since the contact form has a select form tag, we require an extra jar as Selenium dependency to handle select tags. Therefore we add the following dependency to our pom.xml.

<dependency>
    <groupId>org.seleniumhq.selenium</groupId>
    <artifactId>selenium-support</artifactId>
    <version>2.45.0</version>
</dependency>

<groupId>org.seleniumhq.selenium</groupId>

<artifactId>selenium-support</artifactId>

</dependency>

Next step is to define our ContactPage which extends from geb.Page. The static at attribute represents the condition for Geb to verify the browser is at the defined page.

class ContactPage extends Page {

   static url = "contact"

   static at = { heading.text() == "Contact" }

   static content = {
     heading { $("h2") }
     contactForm { module ContactFormModule }
   }
}

class ContactPage extends Page {

static url = "contact"

static at = { heading.text() == "Contact" }

static content = {

heading { $("h2") }

contactForm { module ContactFormModule }

}

The static url string represents the suffix which will be added to the baseUrl to navigate to the Contact page.

In the static closure content block we define our content which is on the Contact page. For the JDriven website we define for now the header and the contact form. As you can see there is a reference to the the ContactFormModule which is defined below. The mechanism to define module content is the similar to the way we define page content.

class ContactFormModule extends Module {

  static content = {
      nameInput{ $("#name") }
      emailInput { $("#from") }
      subjectSelect { $("#subject") }
      bodyTextArea { $("#body") }
      submitButton {$('#fsc-submit') }
  }

  void  fillInValidEntries() {
     nameInput.value("Geb spock test")
     emailInput.value("geb@dummytest.com")
     subjectSelect.value("Overige")
     bodyTextArea.value("Hi, I'm running the Geb spock test from the blog post")
  }

   void submitForm(){
     submitButton.click()
  }

}

class ContactFormModule extends Module {

static content = {

nameInput{ $("#name") }

emailInput { $("#from") }

subjectSelect { $("#subject") }

bodyTextArea { $("#body") }

submitButton {$('#fsc-submit') }

}

void fillInValidEntries() {

nameInput.value("Geb spock test")

emailInput.value("geb@dummytest.com")

subjectSelect.value("Overige")

bodyTextArea.value("Hi, I'm running the Geb spock test from the blog post")

}

void submitForm(){

submitButton.click()

}

Next step is to create our test class which is done below.

class ContactFormSpec extends GebReportingSpec {

   def "Navigate to contact form and fill in valid form"() {

      given:
      to ContactPage

      and:
      page.contactForm.fillInValidEntries()

      when:
      page.contactForm.submitForm()

      then:
      at ContactPage
      assert driver.currentUrl.endsWith("success=true")
      assert page.contains("Wij hebben uw bericht ontvangen. Wij nemen binnenkort met u contact op.")

   }

}

class ContactFormSpec extends GebReportingSpec {

def "Navigate to contact form and fill in valid form"() {

given:

to ContactPage

and:

page.contactForm.fillInValidEntries()

when:

page.contactForm.submitForm()

then:

at ContactPage

assert driver.currentUrl.endsWith("success=true")

assert page.contains("Wij hebben uw bericht ontvangen. Wij nemen binnenkort met u contact op.")

}

As we can see creating Pages and Modules in Geb is very easy and straightforward. The huge benefit we have now, is that we can easily reuse pages and modules in other tests.

Written with Groovy 2.4.3.

Grails Goodness: Adding Health Check Indicators

Posted on April 30, 2015 by mrhaki

With Grails 3 we also get Spring Boot Actuator. We can use Spring Boot Actuator to add some production-ready features for monitoring and managing our Grails application. One of the features is the addition of some endpoints with information about our application. By default we already have a /health endpoint when we start a Grails (3+) application. It gives back a JSON response with status UP. Let’s expand this endpoint and add a disk space, database and url health check indicator.

Continue reading →

Grails Goodness: Log Startup Info

Posted on April 29, 2015 by mrhaki

We can let Grails log some extra information when the application starts. Like the process ID (PID) of the application and on which machine the application starts. And the time needed to start the application. The GrailsApp class has a property logStartupInfo which is true by default. If the property is true than some extra lines are logged at INFO and DEBUG level of the logger of our Application class.

Continue reading →

Grails Goodness: Save Application PID in File

Posted on April 28, 2015 by mrhaki

Since Grails 3 we can borrow a lot of the Spring Boot features in our applications. If we look in our Application.groovy file that is created when we create a new Grails application we see the class GrailsApp. This class extends SpringApplication so we can use all the methods and properties of SpringApplication in our Grails application. Spring Boot and Grails comes with the class ApplicationPidFileWriter in the package org.springframework.boot.actuate.system. This class saves the application PID (Process ID) in a file application.pid when the application starts.

Continue reading →

Awesome Asciidoctor: Display Keyboard Shortcuts

Posted on April 27, 2015 by mrhaki

When we want to explain in our documentation which keys a user must press to get to a function we can use the keyboard macro in Asciidoctor. The macro will output the key nicely formatted as a real key on the keyboard. The syntax of the macro is kbd:[key]. To get the desired output we must set the document attribute experimental otherwise the macro is not used.

Continue reading →

Scala Snippet: How to filter a list in Scala

Posted on April 24, 2015 by Arthur

In Scala, filtering and processing collections is easy and elegant. There are many filtermethods available, but the most used will probably the basic filter method.

Here’s a code example of some filtering on my (ex)camera collection.
The filter method will not only work on Lists, but on any Scala collection.

object MyCameraCollection02 {
 
  case class Camera(brand: String, model: String, sensorType: String, yearBought: Int) {
    override def toString: String =
      s"$brand $model \t\t $sensorType \t($yearBought)"
  }
 
  def main(args: Array[String]) {
    val canon5dmarkIII = new Camera("Canon", "5D MkIII", "FF", 2013)
    val canon5dmarkII = new Camera("Canon", "5D MkII", "FF", 2009)
    val canon6d = new Camera("Canon", "6D", "FF", 2014)
    val canon550d = new Camera("Canon", "550D", "APS-C", 2010)
    val canon40d = new Camera("Canon", "40D", "APS-C", 2008)
    val canonIXUS330 = new Camera("Canon", "IXUS 330", "1/2.7", 2001)
    val canonIXUSZ90 = new Camera("Canon", "IXUS Z90", "APS-C", 1999)
    val panasonicGM1 = new Camera("Panasonic", "GM1", "M43", 2014)
    val panasonicFZ20 = new Camera("Panasonic", "FZ20", "1/2.5", 2005)
    val sonyrx100 = new Camera("Sony", "DSC-RX100", "1\"", 2013)
    val sonynex5 = new Camera("Sony", "NEX-5", "APS-C", 2011)
    val sonyr1 = new Camera("Sony", "DSC-R1", "APS-C", 2005)
 
    val myCameras = List(canon5dmarkIII, canon5dmarkII, canon6d, canon550d, canon40d, canonIXUS330, canonIXUSZ90, panasonicGM1, panasonicFZ20, sonyrx100, sonynex5, sonyr1)
    val canonCameras = myCameras filter (_.brand == "Canon") // Every Canon camera I ever owned
    val sonyCameras = myCameras filter (_.brand == "Sony") // Every Sony camera I ever owned
    val pansonicCameras = myCameras filter (_.brand == "Panasonic") // Every Panasonic camera I ever owned
 
 
    // apscCamera's only
    val apscCameras = myCameras filter (_.sensorType == "APS-C")
    println("==APS-C camera's owned==")
    apscCameras foreach println
    println()
 
 
    // Canon camera's which are not full frame. You can filter, filtered lists.
    val canonNonFF = myCameras filter (_.brand == "Canon") filter (_.sensorType != "FF")
    println("==Non-FF camera's owned==")
    canonNonFF foreach println
    println()
 
    // Filter by boolean expressions on class properties
    val apsBefore2012 = apscCameras filter (_.yearBought < 2012)
    println("==APS-C camera's bought before 2012 owned==")
    apsBefore2012 foreach println
    println()
 
    // Filter by combining boolean expressions.
    val ffcamerasBefore2012 = myCameras filter (cam => cam.yearBought < 2012 && cam.sensorType == "FF")
    println("==Every FF Camera I ever owned before 2012==")
    ffcamerasBefore2012 foreach println
    println()
  }
}

object MyCameraCollection02 {

case class Camera(brand: String, model: String, sensorType: String, yearBought: Int) {

override def toString: String =

s"$brand $model \t\t $sensorType \t($yearBought)"

}

def main(args: Array[String]) {

val canon5dmarkIII = new Camera("Canon", "5D MkIII", "FF", 2013)

val canon5dmarkII = new Camera("Canon", "5D MkII", "FF", 2009)

val canon6d = new Camera("Canon", "6D", "FF", 2014)

val canon550d = new Camera("Canon", "550D", "APS-C", 2010)

val canon40d = new Camera("Canon", "40D", "APS-C", 2008)

val canonIXUS330 = new Camera("Canon", "IXUS 330", "1/2.7", 2001)

val canonIXUSZ90 = new Camera("Canon", "IXUS Z90", "APS-C", 1999)

val panasonicGM1 = new Camera("Panasonic", "GM1", "M43", 2014)

val panasonicFZ20 = new Camera("Panasonic", "FZ20", "1/2.5", 2005)

val sonyrx100 = new Camera("Sony", "DSC-RX100", "1\"", 2013)

val sonynex5 = new Camera("Sony", "NEX-5", "APS-C", 2011)

val sonyr1 = new Camera("Sony", "DSC-R1", "APS-C", 2005)

val myCameras = List(canon5dmarkIII, canon5dmarkII, canon6d, canon550d, canon40d, canonIXUS330, canonIXUSZ90, panasonicGM1, panasonicFZ20, sonyrx100, sonynex5, sonyr1)

val canonCameras = myCameras filter (_.brand == "Canon") // Every Canon camera I ever owned

val sonyCameras = myCameras filter (_.brand == "Sony") // Every Sony camera I ever owned

val pansonicCameras = myCameras filter (_.brand == "Panasonic") // Every Panasonic camera I ever owned

// apscCamera's only

val apscCameras = myCameras filter (_.sensorType == "APS-C")

println("==APS-C camera's owned==")

apscCameras foreach println

println()

// Canon camera's which are not full frame. You can filter, filtered lists.

val canonNonFF = myCameras filter (_.brand == "Canon") filter (_.sensorType != "FF")

println("==Non-FF camera's owned==")

canonNonFF foreach println

println()

// Filter by boolean expressions on class properties

val apsBefore2012 = apscCameras filter (_.yearBought < 2012)

println("==APS-C camera's bought before 2012 owned==")

apsBefore2012 foreach println

println()

// Filter by combining boolean expressions.

val ffcamerasBefore2012 = myCameras filter (cam => cam.yearBought < 2012 && cam.sensorType == "FF")

println("==Every FF Camera I ever owned before 2012==")

ffcamerasBefore2012 foreach println

println()

}

Running this example will give you the following result:

==APS-C camera's owned==
Canon 550D 		 APS-C 	(2010)
Canon 40D 		 APS-C 	(2008)
Canon IXUS Z90 		 APS-C 	(1999)
Sony NEX-5 		 APS-C 	(2011)
Sony DSC-R1 		 APS-C 	(2005)

==Non-FF camera's owned==
Canon 550D 		 APS-C 	(2010)
Canon 40D 		 APS-C 	(2008)
Canon IXUS 330 		 1/2.7 	(2001)
Canon IXUS Z90 		 APS-C 	(1999)

==APS-C camera's bought before 2012 owned==
Canon 550D 		 APS-C 	(2010)
Canon 40D 		 APS-C 	(2008)
Canon IXUS Z90 		 APS-C 	(1999)
Sony NEX-5 		 APS-C 	(2011)
Sony DSC-R1 		 APS-C 	(2005)

==Every FF Camera I ever owned before 2012==
Canon 5D MkII 		 FF 	(2009)

==APS-C camera's owned==

Canon 550D APS-C (2010)

Canon 40D APS-C (2008)

Canon IXUS Z90 APS-C (1999)

Sony NEX-5 APS-C (2011)

Sony DSC-R1 APS-C (2005)

==Non-FF camera's owned==

Canon 550D APS-C (2010)

Canon 40D APS-C (2008)

Canon IXUS 330 1/2.7 (2001)

Canon IXUS Z90 APS-C (1999)

==APS-C camera's bought before 2012 owned==

Canon 550D APS-C (2010)

Canon 40D APS-C (2008)

Canon IXUS Z90 APS-C (1999)

Sony NEX-5 APS-C (2011)

Sony DSC-R1 APS-C (2005)

==Every FF Camera I ever owned before 2012==

Canon 5D MkII FF (2009)

original article

Gradle Goodness: Handle Copying Duplicate Files

Posted on April 24, 2015 by mrhaki

In Gradle we can configure how duplicate files should be handled by the Copy task. Actually we can configure how duplicate files are handled by any task that implements the CopySpec interface. For example archive tasks also implements this interface. We must use the setDuplicatesStrategy method to configure how Gradle behaves. The parameter is a value of the enumeration DuplicatesStrategy. We can use the values from the enum class or use String values, which are automatically converted to enum DuplicatesStrategy values.

We can choose the following strategies:

include: default strategy where the last duplicate file ‘wins’.
exclude: only the first found duplicate file is copied and ‘wins’.
warn: shows a warning on the console, but the last duplicate file ‘wins’ like with the include strategy.
fail: the build fails where duplicate files are found.

Continue reading →

Gradle Goodness: Use Git Commit Id in Build Script

Posted on April 23, 2015 by mrhaki

The nice thing about Gradle is that we can use Java libraries in our build script. This way we can add extra functionality to our build script in an easy way. We must use the classpath dependency configuration for our build script to include the library. For example we can include the library Grgit, which provides an easy way to interact with Git from Java or Groovy code. This library is also the basis for the Gradle Git plugin.

Continue reading →

Time libraries in Scala

Posted on April 22, 2015 by Tammo Sminia

Scala has no default way to deal with dates and times. We have a few options.

java.util.Date and java.util.Calendar
These come included with java, so they may do if you don’t need to do much and don’t want to add any dependencies. But they’re horrible and it’s best not to use them.

Joda-Time
http://www.joda.org/joda-time/
The de facto standard date and time library for Java.

nscala-time
https://github.com/nscala-time/nscala-time
A thin scala layer around Joda-Time. This adds some implicit conversions to make it easier to use, like the + and < operators.

import com.github.nscala_time.time.Imports._
DateTime.now + 2.months // returns org.joda.time.DateTime

1 2	import com.github.nscala_time.time.Imports._ DateTime.now + 2.months // returns org.joda.time.DateTime

Java 8
https://docs.oracle.com/javase/8/docs/api/java/time/package-summary.html
If you use java 8 it’s best to use the improved java.time.

Awesome Asciidoctor: Adding Custom Content to Head and Footer

Posted on April 22, 2015 by mrhaki

When we convert our Asciidoctor markup to HTML we automatically get a head and footer element. We can add custom content to the HTML head element and to the HTML div with id footer. We must set a document attribute and create the files that contain the HTML that needs to be added to the head or footer. We have three different document attributes we can set to include the custom content files:

:docinfo: include document specific content. Files to be included must be named <docname>-docinfo.html for head element and <docname>-docinfo-footer.html for footer content.
:docinfo1: include general custom content. Files to be included must be named docinfo.htmtl for head element and docinfo-footer.html for footer content.
:docinfo2: include document specific and general custom content. Files to be included must be named <docname>-docinfo.html and docinfo.html for head element and <docname>-docinfo-footer.html and docinfo-footer.html for footer content.

Continue reading →