Java 7 Coin proposals

I've just found out that Coin project has released final list of Java 7 proposals! You can find them on Joseph Darcy's blog. Among others, list includes few very interesting (from Java dev point of view) things:

• Josh Bloch automatic resource management: ARM proposal
  
• Collection literals from the same author
  
• Improved type inference for generics (a.k.a. Diamond) - proposal
  

Unfortunately, both closures and improved exception handling were dropped from Java 7. Well, maybe next time... Still, enhancements coming with Java 7 seems to be great and - what's important - concentrated on relieving the typical pain of a Java programmer. Keep it that way!

Testing with... Oracle XE

This is rather "infrastructure" than "testing" post.
Sometimes it happens that developer needs to tie his business logic with fixed database provider, just to obtain required functionality. In my case it was Oracle >= 10g and functionality was regular expression support (REGEX_LIKE, REGEXP_INSTR, REGEXP_SUBSTR, REGEX_REPLACE functions). Hence testing code has to refrain from using quick, agile DB backends (as HSQL) and setup something more heavyweight.
Those who happened to install/configure full-blown Oracle know how hard can this be. Fortunately Oracle came up with solution by releasing Oracle XE database. In Linux with dpkg installation is as easy as:

• get DEB package
  
• run dpkg -i package
  
• /etc/init.d/oracle-xe configure
  

And that's it! We have fully-functional Oracle DB in our own host :) Web UI, typically available under http://127.0.0.1:8100/apex/f let user log in as SYS and manage database just as using sqlplus.
There is however one caveat - when connecting via JDBC, user will very probably get stranfge exceptions with error code ORA-12519, meaning "TNS:no appropriate service handler found". Typical SQL exception is:

oracle xe Io exception:
Connection refused
(DESCRIPTION=(TMP=)(VSNNUM=169869568)(ERR=12519)
(ERROR_STACK=(ERROR=(CODE=12519)(EMFI=4))))

This is caused by a bug in how Oracle XE handles monitoring processes, Fix is pretty straightforward:

• execute: ALTER SYSTEM SET PROCESSES=150 SCOPE=SPFILE;
  
• stop db: /etc/init.d/oracle-xe stop
  
• start it again: /etc/init.d/oracle-xe start
  

Voila! Enjoy your integration testing with brand-new Oracle Express Edition.

Groovy!

Most of java devs have already heard about (not-so-new) JDK based dynamic language - Groovy. It's first announcement didn't make an impression on me, as it seemed to me as "one among many". I became interested in it only after presentation on GeeCON (site).
Especially I asked myself - maybe it can prove useful for testing ? Many agilers know that one of biggest obstacles in implementing TDD in company is that no one really wants to write tests - as it takes precious time. Groovy posses some interesting features which can make testing simpler - and faster! In my opinion, following ones are noteworthy:

• closures - passing block of logic code to always-required try catch finally (try-catch) block in IO operations is quite convenient (of course closures are far more potent); also "it" keyword for first argument to shorten closure declaration is one neat trick
  
• "spread dot" operator - no more for-each loops only to obtain one property value from a collection!
  
• safe navigation operator "?." (aka Elvis :) ), shortening few access lines into one
  
• additional helper methods, as findAll(), every(), any(), collect()
  

What I really like in Groovy testing idea is that it shortens TDD development time without sacrificing quality of the final product. Typically, overusing Groovy's shortening syntax in production code would be like shooting self in foot, as it would make code more error-prone and less maintainable. But this can't be applied to test code, as it serves different purpose and in fact could be, let's say, lesser quality that production one.
For those interested I really recommend short presentation about Groovy from GeeCON by Vaclav Pech. You can find it here

Maven2 production profiles- follow up

Quick follow up - simple example of POM with build profiles for different environments. Nothing especial - just to show how to insert profiles and group properties.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
      <modelVersion>4.0.0</modelVersion>
    
    <groupId>pl.jwach.examples</groupId>
    <artifactId>example</artifactId>
    <packaging>jar</packaging>
    <version>0.1.0</version>

    <dependencies>
        ...
    </dependencies>
    <build>
        
        <finalName>${project.artifactId}-${build.env}-${project.version}</finalName>
        
        <plugins>
           ...
        </plugins>
        
        <resources>
            <!-- FILTERED -->
            <resource>
                <directory>src/main/resources/default</directory>
                <filtering>true</filtering>
                <excludes>
                    <exclude>**/lib/*.jar</exclude>
                    <exclude>**/*.someFiles</exclude>
                </excludes>
            </resource>
            <!-- NOT FILTERED -->
            <resource>
                <directory>src/main/resources/external</directory>
                <filtering>false</filtering>
                <includes>
                    <include>**/*.xml</include>
                </includes>
            </resource>
        </resources>
        <!-- DEFAULT FILTERS -->
        <filters>
            <filter>src/main/filters/default/config.properties</filter>
        </filters>
    </build>
    
    <!-- Filters do not have to show the src/main -->
    <profiles>
        <profile>
            <id>preprod-env</id>
            <properties>
                <build.env>preprod-env</build.env>
            </properties>
            <activation>
                <activeByDefault>false</activeByDefault>
            </activation>
            <build>
                <filters>
                    <filter>src/main/filters/preprod-env/config.properties</filter>
                </filters>
            </build>
        </profile>
        <profile>
            <id>prod-env</id>
            <properties>
                <build.env>prod-env</build.env>
            </properties>
            <activation>
                <activeByDefault>false</activeByDefault>
            </activation>
            <build>
                <filters>
                    <filter>src/main/filters/prod-env/config.properties</filter>
                </filters>
            </build>
        </profile>
    </profiles>
</project>

As you can see, all profiles are disabled by default. This is because common configuration with custom properties for local deployment are collected in default profile, as stated in build section of the POM. When additional profile is activated, properties from new filter will override properties from default. Thanks to such solution we can minimize number of disjoint properties and build development product version without any extra effort.

Maven2 for production development

As many Java devs, I regard Maven2 as a great build tool. After accepting sacrifices of "convention over configuration" approach and getting used to usage of plugins (goals), Maven2 speeds up building/testing/deploying a lot. Yet, it's far more potent than simply "define dependencies - build - package" flow. Authors proudly declare M2 to be "software management tool" and I think I could support such statement (in some parts at least).

Particularly, this post is about M2 build profiles. Declared in POM (or global settings.xml file) profiles can alter project build cycle. They can be active by default (see "activeByDefault" node) or activated by -P command-line switch. Profiles offer unique opportunity - creating versions for different deployment environments totally painless! To achieve this, one can define in each profile:

• resources to be included. For example, if each environment has different server count, you can provide different configuration files. Or if servers run different hardware/software, you can for example feed them with different JNI libs.
  
• sources to be complied. This is useful in example when distributing different debug versions (instrumented/pure on QA/production)
  
• Filters! This is one of the simplest and best features. In my case I have to deal with many pre-production environments. Most of them are configured alike,but with different IPs, ports and external services (JNDI, DB pools, RESTs...). But those are properties that can be tokenized and set during filtering, without any additional efforts.
  
• build plugins - but having different build steps for different environments seems a bit crazy :)
  

I should add one useful note - define custom "build env name" property for each profile and include it in final artifact name, just like:

<finalName>${project.artifactId}-${build.env}-${project.version}</finalName>

This will help you maintain ready artifact for your environments.

Automate your GUI for free! With Marathon

Some time ago I was struggling with automation of GUI testing. Problem wasn't typical. Regular flow involved loading our (web) service into external (Java) tool emulating real mobile device, browsing fixed set of pages and taking screenshots. Next those screens were examined for rendering defects.

Obviously, this was great target for automation. This seemed as a hard task, as external testing tool didn't have any API or interface to connect my custom code. As a surprise, I found great (and LGPL) tool - Marathon (http://www.marathontesting.com).

First of all, Marathon supports recording scripts (clicked in app GUI!) that could be saved and replayed. Of course this feature isn't perfect, as Java GUIs tends to use multiple frameworks and custom Swing components. But this can be easily fixed with Jython - main language of Marathon scripts. Integrating Java and Python, it enables user to write custom Java code executed within tested application's Virtual Machine. Wow! This gives developer almost unlimited possibilities. Injecting AWT events, emulating mouse clicks and activating isolated Swing components is easy and straight-forward. Still, without application's sources determining applicable components can be difficult. Thankfully, Marathon offers drop-in console that can be used to freeze application and review it's component tree.

To recap, usage of Marathon helped me reduce time necessary for taking service screenshots by 80%. Also, tool proved to be very potent - from automating GUI to testing Swing applications. As every free tool, it has some issues, but advantages of speeding up tedious tasks are very rewarding.