Spocklight: Mocks And Stubs Returning Sequence of Values

Posted on October 5, 2015 by mrhaki

Creating and working with mocks and stubs in Spock is easy. If we want to interact with our mocks and stubs we have several options to return values. One of the options is the triple right shift operator >>>. With this operator we can define different return values for multiple invocations of the stubbed or mocked method. For example we can use the >>> operator followed by a list of return values ['abc', 'def', 'ghi']. On the first invocation abc is return, the second invocation returns def and the third (and following) invocation(s) return ghi.

Continue reading →

Spocklight: Only Run Specs Based On Conditions

Posted on September 8, 2015 by mrhaki

In a previous blog post we have seen the IgnoreIf extension. There is also a counterpart: the Requires extension. If we apply this extension to a feature method or specification class than the method or whole class is executed when the condition for the @Requires annotation is true. If the condition is false the method or specification is not executed. As a value for the @Requires annotation we must specify a closure. In the closure Spock adds some properties we can use for our conditions:

jvm can be used to check a Java version or compatibility.
sys returns the Java system properties.
env used to access environment variables.
os can be used to check for operating system names.
javaVersion has the Java version as BigDecimal, eg. 1.8.

Continue reading →

Spocklight: Undo Changes in Java System Properties

Posted on September 7, 2015 by mrhaki

If we need to add a Java system property or change the value of a Java system property inside our specification, then the change is kept as long as the JVM is running. We can make sure that changes to Java system properties are restored after a feature method has run. Spock offers the RestoreSystemProperties extension that saves the current Java system properties before a method is run and restores the values after the method is finished. We use the extension with the @RestoreSystemProperties annotation. The annotation can be applied at specification level or per feature method.

Continue reading →

Spocklight: Optimize Run Order Test Methods

Posted on August 31, 2015 by mrhaki

Spock is able to change the execution order of test methods in a specification. We can tell Spock to re-run failing methods before successful methods. And if we have multiple failing or successful tests, than first run the fastest methods, followed by the slower methods. This way when we re-run the specification we immediately see the failing methods and could stop the execution and fix the errors. We must set the property optimizeRunOrder in the runner configuration of the Spock configuration file. A Spock configuration file with the name SpockConfig.groovy can be placed in the classpath of our test execution or in our USER_HOME/.spock directory. We can also use the Java system property spock.configuration and assign the filename of our Spock configuration file.

Continue reading →

Spocklight: Include or Exclude Specifications Based On Class or Interface

Posted on August 28, 2015 by mrhaki

In a previous post we saw how can use the Spock configuration file to include or exclude specifications based on annotations. Instead of using annotations we can also use classes to include or exclude specifications. For example we could have a base specification class DatabaseSpecification. Other specifications dealing with databases extend this class. To include all these specifications we use the DatabaseSpecification as value for the include property for the test runner configuration.

Because Java (and Groovy) doesn’t support real multiple inheritance this might be a problem if we already have specifications that extends a base class, but the base class cannot be used as filter for the include and exclude runner configuration. Luckily we can also use an interface as the value for the inclusion or exclusion. So we could simple create a marker interface and implement this interface for these specifications we want to include or exclude from the test execution.

Continue reading →

Spocklight: Including or Excluding Specifications Based On Annotations

Posted on August 28, 2015 by mrhaki

One of the lesser known and documented features of Spock if the external Spock configuration file. In this file we can for example specify which specifications to include or exclude from a test run. We can specify a class name (for example a base specification class, like DatabaseSpec) or an annotation. In this post we see how to use annotations to have some specifications run and others not.

Continue reading →

Geb Gems: Handling AJAX requests

Posted on June 4, 2015 by Albert van Veen

One of the biggest struggles while testing web applications that use AJAX is dealing with the timing issues caused by asynchronous nature of the request. A common solution is using timeouts to wait for the AJAX call to be completed. This could cause lots of timing issues. Using Geb there is a better way to determine that the AJAX call and its callback has been completed.

In this blog post we will test the W3Schools website which has a button on it which executes an AJAX request: http://www.w3schools.com/ajax/ajax_example.asp

First we change our baseUrl in the GebConfig.groovy file to the w3school site:

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

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

Second we define the W3schools page with the needed content and the makeRequest method which clicks the button.

import geb.Page

class WwwSchoolsAjaxExamplePage extends Page{

  private  static final DEFAULT_DIV_CONTENT = 'Let AJAX change this text'

  static url = "ajax/ajax_example.asp"

  static at = {
      title=="AJAX Example"
  }

  static content = {
      theButton { $(".example button") }
      theResultDiv { $("#myDiv") }
  }

  def makeRequest() {
      theButton.click()
      waitFor { theResultDiv.text()!=DEFAULT_DIV_CONTENT }
  }

}

import geb.Page

class WwwSchoolsAjaxExamplePage extends Page{

private static final DEFAULT_DIV_CONTENT = 'Let AJAX change this text'

static url = "ajax/ajax_example.asp"

static at = {

title=="AJAX Example"

}

static content = {

theButton { $(".example button") }

theResultDiv { $("#myDiv") }

}

def makeRequest() {

theButton.click()

waitFor { theResultDiv.text()!=DEFAULT_DIV_CONTENT }

}

The key statement here is the waitFor line. This will wait till the condition in the closure returns true. The waitFor uses the default timeout configuration which is for Geb 5 seconds.

Next we’re going to make our test which verifies our content has been updated.

import geb.spock.GebReportingSpec

class AjaxRequestSpec extends GebReportingSpec{

  def "Validate if content gets updated after button click"() {

          given:
          to WwwSchoolsAjaxExamplePage

          when:
          makeRequest()

          then:
           theResultDiv.children()[0].text() == "AJAX is not a new programming language."
           theResultDiv.children()[1].text() == "AJAX is a technique for creating fast and dynamic web pages."

  }

}

import geb.spock.GebReportingSpec

class AjaxRequestSpec extends GebReportingSpec{

def "Validate if content gets updated after button click"() {

given:

to WwwSchoolsAjaxExamplePage

when:

makeRequest()

then:

theResultDiv.children()[0].text() == "AJAX is not a new programming language."

theResultDiv.children()[1].text() == "AJAX is a technique for creating fast and dynamic web pages."

}

When you run the now run the test, the test will succesfully verify the updated content of the w3schools website.

Done with Groovy 2.4.3

Spock: Using ConfineMetaClassChanges when using MetaClass mocking

Posted on November 19, 2014 by Albert van Veen

One of the handy features of Groovy is to change the behavior of classes using MOP (Meta-Object Protocol). We change the metaClass property of a class to alter an implementation. You can for example override a static method of a class. See the example below:

class UserSpec extends Specification {

    def “test user”() {
        given:
        // we can mock static methods...
        User.metaClass.static.findByName = { name -> 
            new User(name: ‘Albert’) }
        when:
        User user = User.findByName(‘Albert’)

        then:
        user.name == ‘Albert’

        when:
        // .. but also non-static methods
        user.metaClass.getName = { return ‘Dries’ }

        then:
        user.name == ‘Dries’
    }

}

class UserSpec extends Specification {

def “test user”() {

given:

// we can mock static methods...

User.metaClass.static.findByName = { name ->

new User(name: ‘Albert’) }

when:

User user = User.findByName(‘Albert’)

then:

user.name == ‘Albert’

when:

// .. but also non-static methods

user.metaClass.getName = { return ‘Dries’ }

then:

user.name == ‘Dries’

}

However this way of mocking has a nasty side effect. Since we apply changes on the User on class level, the changes are also applied in all our other test cases. This can have some unexpected behavior in your other tests

To prevent this Spock has introduced the @ConfineMetaClassChanges annotation. This annotation makes sure the class will return to its original state when it was used in our test.

See the example below:

@ConfineMetaClassChanges([User]) // you can add multiple classes in the annotation
class UserSpec extends Specification {
...
}

@ConfineMetaClassChanges([User]) // you can add multiple classes in the annotation

class UserSpec extends Specification {

...

}

Be aware: this means when some other test did changes to the User class without using @ConfineMetaClassChanges, these changes will be still applicable when the test which has @ConfineMetaClassChanges restores the User class to its old state.

Spocklight: Indicate Class Under Test with Subject Annotation

Posted on October 14, 2014 by mrhaki

If we write a specification for a specific class we can indicate that class with the @Subject annotation. This annotation is only for informational purposes, but can help in making sure we understand which class we are writing the specifications for. The annotation can either be used at class level or field level. If we use the annotation at class level we must specify the class or classes under test as argument for the annotation. If we apply the annotation to a field, the type of the field is used as the class under test. The field can be part of the class definition, but we can also apply the @Subject annotation to fields inside a feature method.

Continue reading →

Spocklight: Write Our Own Data Provider

Posted on June 26, 2014 by mrhaki

We can use data pipes to write data driven tests in Spock. A data pipe (<<) is fed by a data provider. We can use Collection objects as data provider, but also String objects and any class that implements the Iterable interface. We can write our own data provider class if we implement the Iterable interface.

Continue reading →