Setting Up Xtend with Maven and eclipse (Luna)

Xtend is currently my favourite alternative language for the JVM (closely followed by Kotlin). Unfortunately, I did not find a good guide of how to set up a Maven project within eclipse (Luna) which uses Xtend.

Specifically the following guide will allow you to allow you to write test cases in Xtend for your existing Java projects. A great way to get started with Xtend I suppose.

The following describes the necessary steps.

  • Install the Xtend plugin for eclipse as described here.
  • Add the xtend-maven-plugin to your pom.xml as follows:
<plugin>
    <groupId>org.eclipse.xtend</groupId>
    <artifactId>xtend-maven-plugin</artifactId>
    <version>2.7.1</version>
    <executions>
        <execution>
            <goals>
                <goal>testCompile</goal>
            </goals>

            <configuration>
                <testOutputDirectory>${basedir}/src/test/java</testOutputDirectory>
            </configuration>

        </execution>
    </executions>
</plugin> 
  • Also add a dependency to the Xtend runtime libraries
<dependency>
    <groupId>org.eclipse.xtend</groupId>
    <artifactId>org.eclipse.xtend.lib</artifactId>
    <version>2.7.1</version>
    <scope>test</scope>
</dependency>
  • Right click the project and select Maven / Update Project … and update the project.
  • Right clock the project and select Properties
  • Go to the Xtend / Compiler page
  • Set as the ouput director src/test/java

  • Go to the folder src/test/xtend. If the folder does not exist, create it.
  • Right clock the folder src/test/xtend and select Build Path / Use As Source Folder
  • Create a package in the new src/test/xtend folder and right click the package. Select New / Xtend class and define a class such as the following:
package de.mxro.async.map.tests
 

import org.junit.Assert
import org.junit.Test
 

class TestThatNumbersAreEqual {
    
    @Test
    def void test() {
        Assert.assertTrue(3 == 3)
    }
    
    
}
  • Immediately after you save the class a translated class should be created in the folder src/test/java

Now, have fun writing tests using Xtend’s concise syntax – while not affecting any step of your build and development workflow!

To see an example configuration in a complete project, also check out async-map on GitHub.

Google’s 10 Minute Test Plan – Attributes

James A. Whittaker, of considerable testing fame, has published both on the Google Testing blog as well as in IEEE Software an article on the so called ’10 Minute Test Plan’. This test plan is also described in detail in the book ‘How Google Tests Software’ (Whittaker, Arbon, and Carollo, 2012). I read all three versions and I think the article on IEEE Software is the quickest and most pleasant to read (however, you will either have to pay for the article or be part of an institution that has subscribed to IEEE xplore).

Now, there are a couple of things I really like about this ’10 Minute Test Plan’. Chiefly, the idea to use attributes as key building blocks to create test plans.

The test plan described by Whittaker is established in a process named ACC; an acronym composed of attributes, components and capabilities, which are to be elicited in the given order. Components and capabilities are rather ‘standard’ in my mind, describing modules of the software under test and desired functionality respectively. Attributes, on the other hand, seemed at first counterintuitive to me. Attributes, in the ACC framework, are simple adjectives or adverbs, which describe what differentiates the software under test from competitors.

First, I thought this is overly simplistic, given that a single adjective might be too broad a concept to describe anything meaningful. However, while applying this ACC process to the Appjangle platform, I found the attributes to be of particular value! Maybe it’s one of those things one needs to try out to appreciate the value. Below, I have collected three examples of adjectives, which could be used to describe a range of products:

Product Attributes Source
Google Sites Searchable

Sharing

Quick

No Technical Knowledge

Customization

Rich Content

(Whittaker, 2012)
King (A Tool to Estimate Network Latency) Accurate

Easy to Use

Fast

Lightweight

(Gummadi et al., 2002)
Appjangle Scalable

Portable

Testable

Connected

One thing I noticed while creating a set of attributes is that there can be lower level (technical) and higher level (business) attributes. For instance, ‘portable’ is a more technical attribute that can easily be verified. ‘Agile’ could be another valid attribute. However, it is one that is arguably more difficult to measure and verify. In that, I found that multiple technical attributes can be thought of as supporting one higher level business benefit. For instance:

Business Attribute Supported By
Flexible Scalable

Modular

Portable

Testable

Concise

Apart from a set of ‘technical attributes’ enabling business attributes, ‘higher level’ business attributes themselves can be enabled by a set of ‘lower level’ business attributes. For instance, for a product to be adaptive, it needs to be both flexible and agile:

Business Attribute Supported By
Adaptive Flexible

Agile

I think both ‘technical’ and ‘business’ attributes are a great way to describe the benefits of products, as well as to assert these benefits through directed tests. However, one thing I didn’t like so much about the ’10 Minute Test Plan’ is the idea to create a test plan in 10 minutes. To come up even with the most rudimentary set of suitable attributes took me hours – but then maybe I’m just too slow!