Groovy adds the inspect method to the Object. This means it is available on all objects in our application. It is like the toString method, but adds some extra formatting. The most notable is the addition of single quotes to String values.
In the following example we see the output of the inspect method on different objects:
There are a lot of methods added to the Java collection classes by Groovy. For example to remove elements from a collection, and indeed modify the collection itself, we can use the removeAll and removeElement methods. With the removeAll method we define a closure with a condition that needs to be true for an element to be removed from the collection. The removeElement method is added to overcome any ambiguity with the standard overloaded remove method for collections with integer values. The remove method accepts both an Object or int value, to remove either an element or an element at the specified index. When the collection contains integer values than the argument is interpreted as index value. The removeElement method will use the remove(Object) method implementation. When the collection is a List Groovy adds the removeAt method. We need to specify the index value of the element we want to remove.
def list = ['Groovy', '=', 'gr8!']
// Groovy adds removeAll method
// to remove items from collection
// that apply to the condition we
// define in the closure.
list.removeAll { it.toLowerCase().startsWith('g') }
// All values starting with a G or g
// are now removed.
// Remember the collection we use the
// removeAll method on is changed.
assert list == ['=']
// Java 8 adds removeIf method with
// a predicate. In Groovy we can implement
// the predicate as closure.
list.removeIf { it instanceof String }
assert list.size() == 0
def values = ['Hello', 'world']
// Groovy adds removeAll(Object[])
// to remove multiple elements
// from a collection.
values.removeAll(['world', 'Hello'] as Object[])
assert values.empty
def items = [1, 2, 3]
// remove method is overloaded
// for Object and index value.
// Because Groovy wraps int to
// Integer object, the method call
// is ambiguous for Integer collections.
items.remove(1)
// We want to remove object
// Integer(1) from the list,
// but item with index 1 is removed.
assert items == [1, 3]
// Groovy adds removeElement
// as alias for remove(Object).
items.removeElement(1)
assert items == [3]
// When the collection is a List
// we can use the removeAt method
// to remove based on index value.
items.removeAt(0)
assert !items
Section titles in our document (titles start with two or more equals signs) are part of the document hierarchy and therefore can be used in a generated table of contents. If we don't want to include a section title in the table of contents we must make the title discrete. The title is styled like a normal section title, but it is no longer part of the document structure as title. Therefore the section title will not be generated in the table of contents. To make a title discrete we must use the attribute discrete for the title.
In the following document we first have a simple document with two section titles. When we generate the HTML for this document we see both titles in the table of contents.
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.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.
In the following example we see that changes to the Java system properties in the first method are undone again in the second method:
As a Spring developer we know how to load a resource in a Service. The prefixes of classpath: and file: are commonly used. But what if we want to load resources from a different location like a database table RESOURCE, with our own prefix db:? The Spring Framework provides some default built-in resource implementations, which can be found in the chapter Resources in the Spring Framework Reference Guide. The URL is prefixed and handled by the corresponding ResourceLoader (JavaDoc). If we want to load a resource from a database table RESOURCE we have to create our own ResourceLoader which triggers on the prefix db:.
Let's create an interface which describes the action of getting a resource based on the resourceName.
Spcok has a lot of nice extensions we can use in our specifications. The AutoCleanup extension makes sure the close() method of an object is called each time a feature method is finished. We could invoke the close() method also from the cleanup method in our specification, but with the @AutoCleanup annotation it is easier and immediately shows our intention. If the object we apply the annotation to doesn't have a close() method to invoke we can specify the method name as the value for the annotation. Finally we can set the attribute quiet to true if we don't want to see any exceptions that are raised when the close() method (or custom method name, that is specified) is invoked.
In the following example code we have a specification that is testing the WatchService implementation. The implementation also implements the Closeable interface, which means we can use the close() method to cleanup the object properly. We also have a custom class WorkDir with a delete() method that needs to be invoked.
