Mutation testing is a technique which allows to discover which parts of our code are not covered by tests. It is similar to a code coverage, but mutation testing is not limited to the fact that a given line was executed during tests. The idea is to modify the production code (introduce mutations) which should change its behavior (produce different results) and cause unit tests to fail. The lack of the failure may indicate that given part was not covered good enough by the tests. The idea of mutation testing is quite old, but it is rather unpopular. Despite the fact I am rather experienced in testing I found it just recently reviewing a beta version of the new book about testing.

PIT is “a fast bytecode based mutation testing system for Java that makes it possible to test the effectiveness of your unit tests”. It is a very young project, but very promising. It offers a set of mutation operators which among others modify conditional statements, mathematical operations, return values and methods calls.

Starting with the recently released version 0.25 PIT (experimentally) supports TestNG based tests (in addition to JUnit based). To use it from Maven it is required to add pitest-maven plugin to pom.xml:

<plugin>
    <groupId>org.pitest</groupId>
    <artifactId>pitest-maven</artifactId>
    <version>0.25</version>
<!--
    <configuration>
        <inScopeClasses>
            <param>info.solidsoft.blog.pitest.*</param>
        </inScopeClasses>
        <targetClasses>
            <param>info.solidsoft.blog.pitest.*</param>
        </targetClasses>
    </configuration>
-->
</plugin>

In many cases it would be enough. inScopeClasses (mutable classes and tests for running) and targetClasses (only candidates for mutation) by default use project groupId and usually can be omitted. There are several options that can be configured in the plugin configuration. “mvn org.pitest:pitest-maven:mutationCoverage” performs modified tests and generates mutation report which by default is saved in target/pit-reports/yyMMddHHmm directory.

A sample report (click to enlarge) for a specified class shows both line coverage and mutation coverage. Despite 100% line coverage (lines with light green background), PIT found that a test data set does not cover properly boundary conditions.

Sample PIT report

Sample PIT report

These posters about SOLID principles were created by me some time ago as a result of reading about alternatives methods of learning and a necessity to apply it in the real world. There are 5 posters about each principle:

  • Single responsibility
  • Open/closed
  • Liskov substitution
  • Interface segregation
  • Dependency inversion

and the one summary page.

How to use it? There are many interesting ways. For example I put the first one on a pinboard in a kitchen when people always look at waiting for water to boil or coffee to brew. I was positively surprised seeing an interest and discussions about subject and created next posters which were hung on top with a 2 weeks delay. After the whole cycle I did a survey on a technical meeting and countable part of attendees declared the posters as a source of knowledge of SOLID principles. I will be happy to hear how did you used it!

SOLID - introduction posters

The text was based on Wikipedia and a very interesting SOLID elaboration – “Pablo’s SOLID Software Development” did by people from LosTechies.com. The illustrative pictures comes also from that e-book in a version mixed by Joey Devilla. Like original materials the slides are available under the terms of Creative Commons Attribution-ShareAlike 3.0 Unported License (which means that you can for example print it and hang in your office).

Let me know if you find it useful. Comments and remarks are also welcome. Thanks!

To be useful automatic tests should run very fast. Otherwise will not be run often during development or even will be ignored in the default configuration on the developer workstations. The simplest rule it to write only small unit tests which test given class having the neighborhood mocked. Nevertheless sometimes it is useful/required to test something in IoC container context (Spring, CDI, Guice) or using embedded database (H2, HyperSQL, Derby). Unfortunately even a few tests of that kind can increase significantly overall test execution time. I had that situation in one of my projects and to prevent using skipTests flag I developed a solution using groups from TestNG and Maven Surefire plugin.

Tests were divided into three groups:
  – very fast real unit tests (all by default) – should be run very often during development (from IDE or by mvn test, mvn package)
  – slower integration but self-sufficient tests (setting up Spring context and/or using embedded H2 database) – should be run at least before commit/push or while working on given part (from IDE or by mvn integration-test, mvn install)
  – real integration tests (requiring access to remote servers – e.g. testing web services or REST) – should be run daily by CI server or by developers working on the integration (mvn install, mvn integration-test with additional profile enabled)

To achieve that given tests (or test classes) have to be marked as “self-integration” or “integration” (at method or class level):

    @Test(groups = "self-integration")
    public void shouldInitializeChainedAppInfoProperly() {

@Test(groups = "integration")
public class FancyWebServiceIntegrationTest {

Maven Surefire plugin should be configured to exclude “self-integration” and “integration” test groups from default execution and add “self-integration” to “integration-test phase:

    <build>
        <plugins>
            (...)
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>${ver.surefire-plugin}</version>
                <executions>
                    <execution>
                        <id>default-test</id> <!-- to override default configuration - in fact: unit tests -->
                        <configuration>
                            <excludedGroups>self-integration,integration</excludedGroups>
                        </configuration>
                    </execution>
                    <execution>
                        <id>self-integration</id>
                        <phase>integration-test</phase>
                        <goals>
                            <goal>test</goal>
                        </goals>
                        <configuration>
                            <groups>self-integration</groups>
                            <reportsDirectory>target/self-integration-surefire-reports/</reportsDirectory>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>

In addition (if needed) the separate separate profile with “integration” test group configured in “integration-test” phase could be created.

    <profiles>
        (...)
        <profile>
            <id>integration</id>
            <build>
                <plugins>
                    <plugin>
                        <groupId>org.apache.maven.plugins</groupId>
                        <artifactId>maven-surefire-plugin</artifactId>
                        <version>${ver.surefire-plugin}</version>
                        <executions>
                            <execution>
                                <id>integration</id>
                                <phase>integration-test</phase>
                                <goals>
                                    <goal>test</goal>
                                </goals>
                                <configuration>
                                    <groups>integration</groups>
                                    <reportsDirectory>target/integration-surefire-reports/</reportsDirectory>
                                </configuration>
                            </execution>
                        </executions>
                    </plugin>
                </plugins>
            </build>
        </profile>
    </profiles>

Working example can be find in AppInfo‘s artificial branch (pom.xml and sample test class). It’s easy to adopt it to your needs.

All three test groups have separate reports format to not override each other. As the extension it could probably possible to merge they into one aggregated test report.

Gdyby istniała mapa obrazująca położenie osób interesujących się Javą oraz technologiami związanymi z JVM to w minioną sobotę w Warszawie na Dolnym Mokotowie można by było zaobserwować bardzo jasny punkt – uczestników konferencji Confitura 2011. Zgodnie z komunikatem organizatorów w tym roku na konferencji pojawiło się około 800 osób. Cieszy, iż tak duża rzesza ludzi chciała w sobotę przyjść (a czasem nawet przyjechać z daleka), aby przez cały dzień móc dowiedzieć się ciekawych rzeczy i pogłębić swoją wiedzę. Gratulacje i podziękowania dla ludzi zaangażowanych w przygotowanie wydarzenia.

Poniżej zamieszczam slajdy z mojej prezentacji o tworzeniu dobrego kodu. Dziękuję obecnym za liczne przybycie i ponawiam prośbę o przesyłanie uwag i sugestii, abym wiedział, które nad którymi elementami szczególnie powinienem jeszcze popracować (pozytywne mogą być w komentarzach, mocno negatywne proszę na priv ;) ).

Tworzenie dobrego kodu dla niewtajemniczonych Confitura 2011 – slajdy

Największa bezpłatna konferencja społecznościowa dotycząca technologii ze świata Java w Polsce odbędzie się 11 czerwca 2011 w Warszawie. W tym roku po raz pierwszy pod nową nazwą – Confitura (dawniej Javarsovia). Sądząc po pierwszych dniach rejestracji frekwencja ma szansę pobić tę z ubiegłego roku (ponad 650 osób).

Tyle żądnych dowiedzenia się czegoś nowego osób w jednym miejscu na pewno cieszy, ale we mnie budzi również trochę obawy, gdyż jedną z ponad dwudziestu zakwalifikowanych prezentacji będzie moja dotycząca fundamentów Software Craftsmanship i tworzenia dobrego kodu (szczęśliwie planowanych jest kilka ścieżek, więc nikt nie będzie na mnie skazany :) ). To wystąpienie (po prezentacjach w WIT i na Politechnice Warszawskiej) wpisuje się w podjętą przeze mnie w ostatnim czasie próbę propagowania (szczególnie wśród studentów i osób zaczynających przygodę z programowaniem) idei i technik pomagających tworzyć lepsze oprogramowanie w sprawiający więcej przyjemności sposób.

Więcej informacji (w tym możliwość zarejestrowania się) na stronach konferencji.

Confitura Logo

I am currently working on a Wicket frontend for AppFuse. I wanted to get know Wicket better and AppFuse seemed to be a good start to make some “real” application. Besides educational benefits for me it should be helpful for AppFuse and Wicket communities as well. In this and following post I will try to describe some of the problems I’ve met on my way.

Generally speaking every Wicket page has to have corresponding markup (html file with placed components). Without it MarkupNotFoundException is thrown in runtime. Implementing Wicket frontend in AppFuse I have found some pages which don’t have corresponding view (like logout or reload cache) and making an empty markup looked at least artificial for me. I tried to find some information how to avoid it, but the most interesting results were some old pages from mailing list archive with broken subsequential links. After some time I’ve dug out TextTemplate. It was the simplest class I’ve found that allows to dynamically generate markup for a Wicket page. It requires to override only two methods: getString() – which returns page template and interpolate() which allows to parametrize template (in our case does nothing). Because I needed only empty template a skeleton implementation was enough.

public class EmptyMarkup extends TextTemplate {

    @Override
    public String getString() {
        return "";
    }

    @Override
    public TextTemplate interpolate(Map<String, Object> variables) {
        return this;
    }
}

Wicket very often uses interfaces which indicate that given class has it own custom implementation of given feature. In case of dynamic markup IMarkupResourceStreamProvider was a key. Sample page with empty markup could look like:

public class NoMarkupPage extends WebPage implements IMarkupResourceStreamProvider {

//normal page implementation

    public IResourceStream getMarkupResourceStream(MarkupContainer container, Class<?> containerClass) {
        return new EmptyMarkup();
    }
}

It worked fine. It could be discussable if it’s worth to write new class and one additional method instead of the empty html file, but I’ve got to know some Wicket internals by the way of my digging and educational effect was achieved. Nevertheless I knew Wicket has some nice tricks, so a asked on the mailing list if there is a better way. The answer came very fast. Igor Vaynberg posted much more compact solution.

public class Logout extends WebPage {

    @Override
    protected void onInitialize() {
        super.onInitialize();

        //some "business logic"
        getSession().invalidate();

        //the key line
        throw new RestartResponseException(Login.class);
    }
}

TestNG is a testing framework created as an annotation driven alternative for JUnit 3 in times when “extends TestCase” was a indispensable part of writing tests. Even now it provides some interesting features like data providers, parallel tests or test groups. In the situation our tests are not executed from IDE it’s often useful to take a look at test result in HTML report. The original TestNG report looks… raw. What is more they are not very intuitive and readable. There is an alternative – ReportNG. It provides better looking and more lucid HTML test reports.

More information about ReportNG can be found at its webpage, but when I tried to use for my AppInfo library in Maven builds running from CI server I had a problem to find any at a glance guide how to use it with Maven. Fortunately there are samples for Ant and Gradle, so I was able to figure it out, but I hope with this post everyone wanting to use ReportNG with Maven will be able to achieve it without any problem within a few minutes.

First, additional dependency has to be added to pom.xml:

<dependencies>
    <dependency>
        <groupId>org.uncommons</groupId>
        <artifactId>reportng</artifactId>
        <version>1.1.2</version>
        <scope>test</scope>
        <exclusions>
            <exclusion>
                <groupId>org.testng</groupId>
                <artifactId>testng</artifactId>
            </exclusion>
        </exclusions>
    </dependency>
    (...)
</dependencies>

Usually in our project newer TestNG version is used, so that ReportNG dependency should be excluded.

Next, Surefire plugin has to be configured:

<build>
    <plugins>
        <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.5</version>
            <configuration>
                <properties>
                    <property>
                        <name>usedefaultlisteners</name>
                        <value>false</value>
                    </property>
                    <property>
                        <name>listener</name>
                        <value>org.uncommons.reportng.HTMLReporter, org.uncommons.reportng.JUnitXMLReporter</value>
                    </property>
                </properties>
                <workingDirectory>target/</workingDirectory>
            </configuration>
        </plugin>
        (...)
    </plugins>
</build>

ReportNG uses two reporters pluggable into TestNG. JUnitXMLReporter generates XML summarize of running tests. It’s used for tools (like CI server). HTMLReporter creates human readable HTML report. Default TestNG listeners should be disabled.

After test run I added also workingDirectory property which causes that velocity.log (file created by Velocity engine used internally by ReportNG) is placed in target instead of main project directory (and therefor is deleted by “mvn clean” command).

One more thing. Unfortunately ReportNG jar isn’t available in Maven Central Repository, so could be required to add java.net repository in your settings.xml.

<repositories>
    <repository>
        <id>java-net</id>
        <url>http://download.java.net/maven/2</url>
    </repository>
    (...)
</repositories>

That’s all. Now “mvn clean test” should generate nice looking HTML report for lots of tests covering our project :) .

On the New Year’s day I released version 0.5.2 of AppInfo – a library providing an easy way to versioning your application. More about AppInfo I wrote in my previous post – step by step tutorial how to use it. In 0.5.2 ManifestReader hierarchy was internally refactored (duplication was removed, better coverage provided). I made also test and code coverage reports create automatically by CI server publicly available – I have no reason to be ashamed of my code. After all, working code is not enough :) .

AppInfo is a small library which provide the easy way to show always valid, automatic updated information about a version of running software in a web/desktop Java application. This is especially useful in connection with builds from Continuous Integration server which are automatically deployed on QA environment.

In this post I will show how easy is to setup versioning using AppInfo.

Besides AppInfo supports both web and desktop applications with or without Spring Framework in this example very simple console application with Spring is used to make post possible short and easy to understand. Maven is used as a build tool.

Our console application contains class which is run from main. In original version it only prints welcome banner on the console and initialize Spring context.

package net.sf.appinfo.spring.example;

//required imports

public class AppInfoSpringExample {

    protected final Logger log = LoggerFactory.getLogger(getClass());

    private ApplicationContext context;

    public static void main(String args[]) {
        AppInfoSpringExample app = new AppInfoSpringExample();
        app.start();
    }

    private void start() {
        initSpringContext();
        printAppInfo();
    }

    private void printAppInfo() {
        log.info("Welcome to AppInfo Spring Example");
    }

    private void initSpringContext() {
        context = new ClassPathXmlApplicationContext(
                "classpath:net/sf/appinfo/spring/example/applicationContext.xml");
    }
}

The output is:

[main] INFO  n.s.a.s.example.AppInfoSpringExample - Welcome to AppInfo Spring Example

It is not enough – we want to add version info. AppInfo to the rescue!

Step 1. Add AppInfo dependency in Maven.

        <dependency>
            <groupId>net.sf.appinfo</groupId>
            <artifactId>appinfo</artifactId>
            <version>0.5.1</version>
        </dependency>

AppInfo is available in Maven Central Repository, so it’s very easy to configure dependency using Maven (also Ivy or Grails). It will be automatically downloaded during the next build.

Step 2. Configure manifest reader from AppInfo in Spring configuration file (here applicationContext.xml) to get information from the main application JAR.

    <!-- the only bean required by AppInfo -->
    <bean id="applicationTypeSpecificManifestReader" class="net.sf.appinfo.reader.JarManifestReader">
        <!-- class from a JAR which is the application run from -->
        <constructor-arg value="net.sf.appinfo.spring.example.AppInfoSpringExample"/>
    </bean>

It’s required to configure that one bean with class from the application to allow AppInfo to get MANIFEST.MF from JAR in which application is packaged (there are many other JARs on a classpath).

Step 3. Modify Spring context configuration to attach one additional XML file from AppInfo package.

    private void initSpringContext() {
        context = new ClassPathXmlApplicationContext(
                "classpath:net/sf/appinfo/spring/example/applicationContext.xml",   //original application configuration
                "classpath:net/sf/appinfo/appInfoDefaultContext.xml");  //additional configuration from AppInfo
    }

Step 4. Add displaying information about current application version.

    private void printAppInfo() {
        log.info("Welcome to AppInfo Spring Example");  //original line
        String appInfoText = context.getBean("appInfoText", String.class);
        log.info("The application info is: {}", appInfoText);
    }

AppInfo in default configuration for Spring creates appInfoText bean which contains textural representation of current application version. It’s only required to inject into some other bean or fetch from Spring context and use in some other way (e.g. like presented above).

Step 5. Modify maven-jar-plugin to attach additional manifest entries.

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-jar-plugin</artifactId>
                <configuration>
                    <archive>
                        <manifest>
                            <addClasspath>true</addClasspath>
                            <mainClass>net.sf.appinfo.spring.example.AppInfoSpringExample</mainClass>
                        </manifest>
                        <!-- AppInfo related entries below -->
                        <manifestEntries>
                            <Specification-Title>${project.name}</Specification-Title>
                            <Specification-Version>${project.version}</Specification-Version>
                            <!-- Variables set by Hudson -->
                            <Build-Number>${BUILD_NUMBER}</Build-Number>
                            <Build-Date>${BUILD_ID}</Build-Date>
                            <SCM-Revision>${SVN_REVISION}</SCM-Revision>
                        </manifestEntries>
                    </archive>
                </configuration>
            </plugin>

Build process has to store information about application version. In the default implementation MANIFEST.MF is used. When building automatically, CI server provides that data. Below sample configuration for Hudson CI server.

Step 6. Test run.

To simulate build from CI server it is required to set a few system variable which are normally set by Hudson. This can be done using following command:
$ BUILD_NUMBER=12 SVN_REVISION=12345 mvn clean package

After successful build the application need to be run:
$ java -jar target/appinfo-spring-example-0.5.1-SNAPSHOT.jar

The result is:

[main] INFO  n.s.a.s.example.AppInfoSpringExample - Welcome to AppInfo Spring Example
[main] INFO  n.s.a.s.example.AppInfoSpringExample - The application info is: AppInfo Spring Example - 0.5.1-SNAPSHOT - Build 12 - Rev. 12345 - devel

Build number and SCM revision is set. Build date wasn’t set, so have default value.

Integration with web application can be done in similar manner. For more information check the project home page.

Please let me know if you think that tutorial was helpful (and generally if AppInfo is useful for you – I’m also author of AppInfo library). Next time I could prepare some more complicated example. Sources for that example are available in AppInfo’s Git repository, which can be clonned by:

git clone git://appinfo.git.sourceforge.net/gitroot/appinfo/appinfo-spring-example

Recently I was playing a little with Hades. Generic DAO implementation which can reduce writing a lot of boiler plate code. So far so good, but I wanted to test some mappings with bidirectional relationship using automated tests. The feature of Hibernate (and JPA implementations in general) is an ability to cache some operations in Session/EntityManager (the first level cache) reducing number of statement sending to database. Generally it’s useful, but when you try to test some DAO operations with rollback at the end of a test (instead of commit) it complicates a few things. Sample situation, persist some object. Hibernate memorize that object should be created in database, but waits with sending insert statement on flush, commit (which causes flush) or related query which needs to have that data in database to perform (like findAll). Using rollback causes that there could be no flush (all read/write operations are performed within EntityManager) and some problems which occur in normal usage from end application could remain undiscovered.
The first idea how to solve that is to call flush on EntityManager, but DAO interface in Hades (and hopefully any other custom made generic DAO) doesn’t offer that command. It could be quite dangerous to give a developer an ability to call flush whenever he/she likes in the application (at least it could have the negative performance impact). Ok, the second idea is to cast interface to it’s implementation. Even in Hades implementation has protected getEntityManager method to allow to use EntityManager directly in specified DAOs. Let’s play. Small utility class in the same package, cast DAO interface to GenericDaoSupport and…

java.lang.ClassCastException: $Proxy38 cannot be cast to org.synyx.hades.dao.orm.GenericJpaDao

Ups, something is wrong. The problem is that our DAO interface implementation autowired with our test is not directly GenericJpaDao, but proxy object made by Spring. It’s not even Hades specific issue. Similar situation could happen when home made generic DAO is used with Spring.

Looking at Spring proxy object in debugger shows it’s a quite complicated object and it wouldn’t be easy to “find” target object. What is more I try to not use dirty hacks when not needed, so I started to look for some other way to get target class using Spring mechanisms itself. After some digging I have found Advised interface which Spring proxy implements. With its help it is possible to do:

targetObject = ((Advised)daoInterface).getTargetSource().getTarget();

which can be without further problems cast to GenericJpaDao which offers getEntityManager. Having EntityManager it’s simple to do flush or detach on given entity. I have found it useful to create an util class offering mentioned functionality for the usage in DAO tests across the project.

package package.with.your.dao.implementation;

import required.classes;

/**
 * Utility class allowing to get EntityManager (to perform flush and/or detach) from DAO interface (available even as Spring proxy).
 *
 * Licensed under the terms of Apache Software License version 2.
 *
 * @author Marcin Zajączkowski, http://solidsoft.wordpress.com/
 */
public final class DaoTestUtil {

    private DaoTestUtil() {
    }

    public static EntityManager getEntityManagerFromSpringEnhancedDaoInterface(GenericDao<?, ?> daoInterface) {

        try {
            Object targetObject = null;
            if (daoInterface instanceof Advised) {
                //Spring proxy
                targetObject = ((Advised)daoInterface).getTargetSource().getTarget();
            } else {
                targetObject = daoInterface;
            }

            GenericJpaDao daoImpl = (GenericJpaDao)targetObject;
            return daoImpl.getEntityManager();
        } catch (Exception e) {
            throw new IllegalArgumentException("Unable to get GenericJpaDao from " + daoInterface.getClass().getName(), e);
        }
    }

    public static void doFlushAndDetachEntityUsingEntityManagerFromDao(GenericDao<?, ?> daoInterface, Object entityDoDetach) {
        EntityManager em = getEntityManagerFromSpringEnhancedDaoInterface(daoInterface);
        em.flush;
        em.detach(entityDoDetach);
    }
}