Run one or Exclude one test with Gradle

From time to time you only want to run one test, one test method, one class or one package from the command-line.

Or on the contrary: you want to exclude / ignore one specific test or group of tests during the build cycle.

Excluding tests from the build cycle by the command line usually occurs when the following scenarios meet:

  • A test requires significant amount of resources (time, memory, disk space, etc.)
  • The run needs to be independent from the IDE (to reenact the Continuous Integration / Continuous Delivery pipeline) as some IDEs load test-dependencies on the compile-time class-path.
  • You have no or limited ability to change the code-base

Continue reading

Run one or Exclude one test with Maven

From time to time you only want to run one test, one test method, one class or one package from the command-line.

Or on the contrary: you want to exclude / ignore one specific test or group of tests during the build cycle.

Excluding tests from the build cycle by the command line usually occurs when the following scenarios meet:

  • A test requires significant amount of resources (time, memory, disk space, etc.)
  • The run needs to be independent from the IDE (reenact the Continuous Integration / Continuous Delivery pipeline) as some IDEs load test-dependencies on the compile-time class-path.
  • You have no or limited ability to change the code-base
    Continue reading

Spocklight: Reuse Variables In Data Providers

Writing a parameterized specification in Spock is easy. We need to add the where: block and use data providers to specify different values. For each set of values from the data providers our specifications is run, so we can test for example very effectively multiple input arguments for a method and the expected outcome. A data provider can be anything that implements the Iterable interface. Spock also adds support for a data table. In the data table we define columns for each variable and in the rows values for each variable. Since Spock 1.1 we can reuse the value of the variables inside the data provider or data table. The value of the variable can only be reused in variables that are defined after the variable we want to reuse is defined.

Continue reading

Extending Selenium with page objects

As all who have used it know Selenium is a powerful tool when testing front-end applications. I personally use it in combination with protractor. This is because most of the work I do is with Angular and AngularJS applications.

When you are using Typescript extending classes is an easy thing. In light of this I’ve been experimenting with new approaches to creating page objects. Continue reading

Test code separation

As someone who spends quite some time writing and checking unit and e2e tests I’ve started noticing a trend I’m somewhat confused by. There have been multiple occasions in which I’ve encountered test logic (repeatable and single use) in either test specifications or page objects.

So I decided to share my approach to writing and foremost separating my test code into three categories. Those being: Specifications , Sequences and Page Objects.

Continue reading

Spocklight: Set Timeout On Specification Methods

When we write a feature method in our Spock specification to test our class we might run into long running methods that are invoked. We can specify a maximum time we want to wait for a method. If the time spent by the method is more than the maximum time our feature method must fail. Spock has the @Timeout annotation to define this. We can apply the annotation to our specification or to feature methods in the specification. We specify the timeout value as argument for the @Timeout annotation. Seconds are the default time unit that is used. If we want to specify a different time unit we can use the annotation argument unit and use constants from java.util.concurrent.TimeUnit to set a value.

Continue reading

Spocklight: Ignoring Other Feature Methods Using @IgnoreRest

To ignore feature methods in our Spock specification we can use the annotation @Ignore. Any feature method or specification with this annotation is not invoked when we run a specification. With the annotation @IgnoreRest we indicate that feature methods that do not have this annotation must be ignored. So any method with the annotation is invoked, but the ones without aren’t. This annotation can only be applied to methods and not to a specification class.

Continue reading

Unit testing an AngularJS directive’s private functions.

As we all know Javascript gives us the awesome ability to create functions inside functions. This allows us to create private functions which support the main function. It is also something we do often when creating object functions. This structure is used by angular for the creation of providers and directives alike.

Every once in a while I personally come to a point where I would like to test these private functions. This is especially true for use cases in Angular such as directives. Continue reading

Geb Gems: Using Pages and Modules

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

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.

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.

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.

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

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.

Nifty JUnit : Using Rule on Method and Class level

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.

Method 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.

Class Rule

Besides the regular @Rule we have the possibility to create a @ClassRule. In the example of the TemporaryFolder it will result in a folder which is created before all test methods (just like @BeforeClass) and destroyed after all test methods (just like @AfterClass). In the example below you can create a temporary file and use the exact same file in all the test methods. The temporary file will be deleted when all the test methods are finished.