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/"
Continue reading →
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()
}
}
Continue reading →
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
Continue reading →
When we a have Spring managed application, we want to let Spring manage all of our beans. Beside the regular way of creating beans with known solutions like Annotated beans, Java Configuration and XML Configuration, there is also a way in which we can create our own BeanDefinition. With a BeanDefinitionRegistryPostProcessor it is possible to create a specific post processor which can add BeanDefinitions to the BeanDefinitionRegistry. It differs from the BeanPostProcessor, which only has hooks for Bean Initialization (construction of your POJO), where the BeanDefinitionRegistryPostProcessor has a hook on the BeanDefinitionRegistry. This gives us the ability to define our own BeanDefinition. First we create a BeanDefinitionRegistryPostProcessor implementation as listed in the example. We implement the required method, and will be able to add our own bean definition to the registry. The defined BeanDefinition will be picked up by the ApplicationContext and the POJO will be constructed. Our result is A Spring managed bean
package com.jdriven;
import org.springframework.beans.BeansException;
import org.springframework.beans.factory.support.BeanDefinitionRegistry;
import org.springframework.beans.factory.support.BeanDefinitionRegistryPostProcessor;
import org.springframework.beans.factory.support.RootBeanDefinition;
import org.springframework.stereotype.Component;
@Component
public class LogicServiceRegistryPostProcessor
implements BeanDefinitionRegistryPostProcessor {
@Override
public void postProcessBeanDefinitionRegistry(BeanDefinitionRegistry registry)
throws BeansException {
RootBeanDefinition beanDefinition =
new RootBeanDefinition(MyServiceImpl.class); //The service implementation
serviceDefinition.setTargetType(MyService.class); //The service interface
serviceDefinition.setRole(BeanDefinition.ROLE_APPLICATION);
registry.registerBeanDefinition("myBeanName", beanDefinition );
}
}
Continue reading →
Geb is framework which makes it easy to create functional tests for your application. Since you can use Groovy, Spock and the elegance of the JQuery selector, you can setup solid functional test very easy. In this blogpost we will make a simple test which will test a functional part of the JDriven website. We will start our test with configuring the Maven POM file. We need to add the following dependencies.
<dependencies><dependency>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
<version>2.4.3</version>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.spockframework</groupId>
<artifactId>spock-core</artifactId>
<version>1.0-groovy-2.4</version>
<scope>test</scope>
<exclusions>
<exclusion>
<groupId>org.codehaus.groovy</groupId>
<artifactId>groovy-all</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.gebish</groupId>
<artifactId>geb-spock</artifactId>
<version>0.10.0</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.seleniumhq.selenium</groupId>
<artifactId>selenium-firefox-driver</artifactId>
<version>2.45.0</version>
<scope>test</scope>
</dependency>
</dependencies>
Continue reading →
In Scala there exist the construct of a 'case class'. According to Martin Odersky this supports you to write a "regular, non-encapsulated data structure". It always seems to be associated with pattern matching. So when to use a case class and when to use a 'plain' class? I found this nice explanation stating: _"Case classes can be seen as plain and immutable data-holding objects that should exclusively depend on their constructor arguments. This functional concept allows us to
- use a compact initialisation syntax (Node(1, Leaf(2), None)))
- decompose them using pattern matching
- have equality comparisons implicitly defined
Continue reading →
In Groovy we can use the sort and unique methods to sort a collection or remove duplicates from a collection. These methods alter the collection on which they are invoked. This is a side effect we might want to avoid. Therefore the sort and unique methods where changed and we could pass a boolean argument to indicate if the original collection should be changed or that we must have a new collection as the result of the methods, leaving the original collection untouched. Since Groovy 2.4 we have two new methods which by default return a new collection: toSorted and toUnique.
In the following sample we see the new methods in action:
Continue reading →
When we construct an typed Array out of an existing List, we use the method T[] toArray(T[] a). When an array with a lower size than the size of the List is passed as argument, this results in a new array being created. Take a look at the implementation of ArrayList here. Using the method with an incorrect sized array is inefficient. Using the toArray method directly with a correctly sized array is therefore preferable.
ArrayList myList; //Assume myList has some added entries
//Size is too small a 2nd array will be created
MyClass[] arr = myList.toArray(new MyClass[0]);
Continue reading →
I would like to show different ways of using Spring's @Autowired annotation: Constructor, Method and Field autowiring.
The examples I show are all a form of byType autowiring mode (constructor autowiring mode is Analogous to byType). Take a look at the Spring Reference guide for more information on the Autowiring modes.
Create a constructor with a dependent bean as constructor parameter and add the @Autowired annotation to the constructor. A big advantage of autowiring by constructor is that the field can be made final, and therefore may not be changed after construction.
Continue reading →
Suppose I want to make coffee. This involves 4 steps:
- 1a. grind coffee beans
- 1b. heat water
- combine
- filter
Continue reading →
As shown in a the post Nifty JUnit : Working with temporary files, it is possible to use @Rule in a JUnit test, which is a Method level Rule. In this example I would like to show the variation of the @ClassRule for a Class level Rule.
The @Rule is fired before each test method (just like @Before) and after each test method (just like @After) of the test class, as shown in the example below.
Continue reading →
We have to deal with legacy code, even when we would like to use the best and newest technologies available. Imagine the new code is written with the newest technologies of the Spring Framework and the legacy code is not written in Spring at all. Then using Spring managed Beans in non-managed Spring objects is one of the patterns we have to deal with. The legacy code has non-managed Spring objects, while the code we want to reference to is a Spring managed Bean. How do we solve this problem?
Let's assume we have a managed Spring Bean called TaxService and an object called LegacyObject. The LegacyObject is the legacy code from where we would make a reference to the method calculateTax on the managed Spring Bean.
Continue reading →
