Executing JUnit Runners Outside Of JUnit

I received a comment on one of my previous posts asking how to run a test class using SpringJUnit4ClassRunner from normal application code (i.e. within a main method). I'll admit, I didn't know how to do this, but my interest was piqued, and so I ran off to an existing test class I had laying around. Within a few minutes, I had a working prototype. Here it is:

Making a Move Forward

Today I made some commitments to present some "lightning-talks" on .NET topics for my local .NET user group. I may be giving some discussions on C# basics, HTML5 topics, LESS(CSS), and JavaScript. Like many others who are working in the presentation/evangelism circuit, I feel that this will help force me into showing off some talents that I do have and learning some things that I currently don't know.

Follow the Evansville .NET User Group homepage for more details.

Java Problem: Generic Inheritance and Calling GetMethod().getReturnType()

In my current project, I have classes which are modeled like the following. At some point, a method like getReturnTypeForGetId() is called on classes A and B. Calling the method with A returns Integer as expected, but B returns Serializable.

What am I missing here? Am I getting bitten by some heinous erasure thing, or am I just missing out on some sort of generic context-clobbering?

EDIT: Adding an over-ridden getId() method to B fixes the problem, but I would still like to understand what I am running into.

I've also asked this question on stackoverflow.

import java.io.Serializable;

public class WeirdTester {
    static interface Identifiable<T extends Serializable> {
        T getId();
        void setId(final T id);
    }

    static abstract class BaseEntity<T extends Serializable> implements Identifiable<T> {
        private T id;
        public T getId() { return id; }
        public void setId(final T id) { this.id = id; }
    }

    static class A implements Identifiable<Integer> {
        private Integer id;
        public Integer getId() { return id; }
        public void setId(final Integer id) { this.id = id; }
    }

    static class B extends BaseEntity<Integer> {}

    @SuppressWarnings("unchecked")
    private static <T extends Serializable, Q extends Identifiable<T>> Class<T> getReturnTypeForGetId(
            final Class<Q> clazz) throws Exception {
        return (Class<T>) clazz.getMethod("getId", (Class[])null).getReturnType();
    }

    public static void main(final String[] args) throws Exception {
        System.out.println(getReturnTypeForGetId(A.class));
        // CONSOLE: "class java.lang.Integer"
        System.out.println(getReturnTypeForGetId(B.class));
        // CONSOLE: "interface java.io.Serializable"
    }
}

Quick Hint: Command-line tools for MonoDevelop on Mac OS X

In doing some investigation for doing contract-first development for web services on .NET, I ran into the wsdl command-line tool. Unfortunately, I was unable to find its equivalent in the MonoDevelop IDE. I finally did some digging around in the terminal and found the MonoDevelop command-line tools at: /Library/Frameworks/Mono.framework or /Library/Frameworks/Mono.framework/Versions/current/bin.

Using MonoDevelop to Create an ASP.NET Web Service

NOTE: instructions below are for MonoDevelop 2.6 Beta 2 - built on 2011-04-06 03:37:58+0000

Getting Started

Create a new ASP.NET Web Application in MonoDevelop:

1. From the menu, select: File → New → Solution…
2. Expand C#.
3. Select ASP.NET → Web Application.
4. Enter a name for the ASP.NET project that will be created in the solution in Name:.
5. Change the root location for the solution in Location:, if desired.
6. Change the name of the root solution in Solution Name:, if desired.

The Results – I

What you have after executing the new ASP.NET Web Application project wizard is a solution containing one ASP.NET Web Application project. In the default project view in MonoDevelop, you'll find the following items:

• Default.aspx – This is the default web form rendered and presented in the browser when http://<server>:<port>/ is accessed.
  • Default.aspx.cs – This C# file contains the developer-created common code and event handlers which can be used to affect the processing of the form.
  • Default.aspx.designer.cs – This C# file contains the IDE-generated code for the page.
  Both of the above files contain partial class definitions which are compiled together into a single code-behind class at runtime.
• Global.asax – This file contains the basic information which is available to the entire application.
• Global.asax.cs – This C# file contains methods and event handlers for the entire application. These include event handlers for: application initialization, application termination, session handling, error handling, and request handling.
• web.config – This file contains the primary configuration for the application when deployed to a server. A secondary set of configuration options can be found in the server's Machine.config file.

If you go out to the location where you created the solution/project, you will also find a few other files:

• /<solution name>/<solution name>.sln – This file contains configuration information for the entire "workspace" of projects.
• /<solution name>/<solution name>.userprefs – This file is generated by MonoDevelop and contains information specific to the user of the MonoDevelop application. The consensus is that this file should not be included in source-control.
• /<solution name>/<project name>/<project name>.csproj – This file contains configuration information for the particular project.
• /<solution name>/<project name>/<project name>.pidb – This binary file contains meta-data generated by MonoDevelop. The consensus is also that this file should not be included in source-control.

Setting Up the Web Service

Since I'm only really interested in exposing a web service using this project, I felt that I really don't need the Default.aspx.* or Global.asax.* files as they are currently not doing anything for the project. I deleted all five of the files.

Create a new ASP.NET Web Service file in MonoDevelop:

1. In the Solution pad, right-click your project and select: Add → New File…
2. Select ASP.NET → Web Service.
3. Enter a name for the file that will be created in the project in Name:.

The Results – II

After the ASP.NET web service wizard has completed, you'll find a new asmx file in your project. This file will contain the basic WebService directive, some using statements (System and System.Web.Services), a namespace, and a class definition.

Exposing a Method in the Web Service

Next, you'll want to create a method that you want to expose as a method on your web service. Add the WebMethod attribute to it. Your asmx file will now look something like this:

When you run this project, you can view a simple front-end for the service at http://localhost:8080/<web service file name>.asmx. This web form is created at runtime by the ASP.NET container.

What? No code-behind?

While it is normally a good practice to separate a view from the code which contains its logic, as in an aspx file, there is really no reason to do so in an asmx file as there is no visual component which must be separated from the code.

Getting Started with .NET on the Mac

I'm setting out to learn .NET and get some experience creating a non-trivial project. Microsoft does provide Express (free, Windows-only) editions of the Visual Studio application in a few flavors as well as basic version of IIS with ASP.NET and SQL Server. But, since my current personal development environment is a MacBook Pro (OSX 10.6.7), getting started with development on .NET can actually cost money (mostly due to the Windows tax). The primary development tool for .NET developers on non-Windows systems seems to be Mono with MonoDevelop.

The latest stable release of Mono (2.10.1) supports much of the functionality of the .NET 4.0 platform and some portions of Microsoft's extended .NET eco-system: F#, IronRuby, IronPython, ASP.NET MVC(1, 2, and portions of 3).

The latest beta build of MonoDevelop (2.6 beta 2) provides a lot of support for developing applications using C# and the rest of the CLR.

I'll be using these in the coming months to do some experiments in the creation of a blogging engine in .NET. As part of proving that I can work in the .NET world. You can see the results of my experiments on my github page.

Mono also provides two other interesting projects:

• Mono for Android -- run .NET applications on Android devices.
• MonoTouch -- run .NET applications on iOS devices (iPhone, iTouch, iPad).

Testing Toolbelt: Testing non-xml attributes of responses in SoapUI

I spend a large part of my time developing web services, so I spend a lot of my time testing web services. One of the major tools I have in my toolbelt for automating web service tests is SoapUI. SoapUI does a lot of things, and even does a lot of things which I don't need, but it does the things I need very well. Today, I was trying to set up some testing for the security on my current project. As I was setting up the test request and pointing SoapUI at the appropriate endpoints with invalid http basic authorization credentials, I realized that there was no straight forward way to assert that the http response code was 401 (unauthorized) or 403 (forbidden). I did some digging, and found that you could create a Script Assertion (using Groovy) in the SOAP Test Step and use the pre-defined variable, messageExchange, to examine contents and statistics for the test step.

Asserting that a SOAP request with no credentials was responded to with a 401

Asserting that a SOAP request with invalid credentials was responded to with a 403

The Script Assertion also has access to two other pre-defined variables: context and log. context contains methods which allow you to examine the request and response programmatically and log, well I haven't had to use yet. These are posts for another day.

Maven Note: Securing a temporary Jetty instance in the jetty-maven-plugin

One of my tasks for the current iteration was to add security constraints to the J2EE web service that we are currently developing. This is the easy part. Simply define the appropriate security-constraint, login-config, and security-role elements in the project's web.xml.

web.xml

From the above, you can see that I defined an expected role, AUTHORIZED_USER, an expected realm for http basic authentication, APP, and a set of resources, / and /*, which can only be accessed through SSL by a user who is a member of the AUTHORIZED_USER role. This is the easy part and should work for most application servers which are worth their salt.

Enter jetty-maven-plugin

This project is already using the jetty-maven-plugin to run a test instance of the application. I thought it would be a good idea to make sure that the security on the localhost instance for testing would work in the same manner as the WebSphere server to which the application is to be deployed. This would help me to ensure that I, as a lazy programmer, would not have to change the functional tests (SoapUI) between localhost and dev.

By default, the jetty instance created by executing mvn jetty:run-war does not include a user realm for defining users and groups, a login service for handling attempted logins, or even the capability for handling SSL connections. In order to bring these components into the localhost instance, I had to make some changes to the configuration of my project's jetty-maven-plugin. First, the changes for enabling the user realm and login service.

pom.xml (version 1)

/src/test/resources/jetty-users.properties

Using the keytool-maven-plugin for generating a certificate for SSL

In order to enable server authentication, the Jetty instance needs to have access to a server certificate to be sent out in the SSL handshake. I did some investigation and found that there was a plugin, keytool-maven-plugin, which would allow you to automate self-signed certificate generation in the maven execution. I modified the project's pom as follows:

pom.xml (version 2)

Adding SSL support to Jetty

Now, we have a way for the client to authenticate itself, a realm for assigning that client's roles, and a keystore. We just need to tell Jetty how to expose an SSL port to the world.

pom.xml (version 3)

A big thank-you to mrhaki and his article Configure Maven Jetty Plugin for SSL Communication for the assist.

Testing Toolbelt: SpringJUnit4ClassRunner

The org.springframework.test.context.junit4.SpringJUnit4ClassRunner class is another implementation of the JUnit TestRunner class which is used to enable various features of Spring for every run of the test class and every test within it. To use the features provided by the SpringJUnit4ClassRunner class, you need to mark the class using the RunWith annotation using SpringJUnit4ClassRunner as its parameter.

In addition to the custom test runner, you will want to mark the class with the ContextConfiguration annotation. The ContextConfiguration annotation is used to mark classes which will automatically read a Spring configuration file and use it to create an ApplicationContext. By default, this file located at <package path>/<test class name>-context.xml. Use the locations argument to over-ride.

The ApplicationContext used by the Spring-integrated test will only be loaded once for the whole test class. This behavior can be over-ridden by annotating a test method with the DirtiesContext annotation, which causes the ApplicationContext to be reloaded after the test method completes.

Test Property Injection

Fresh versions of the properties for the test, including the class under test, can be automatically injected for every test, either by name or type. A test class property marked with the Autowired annotation will be automatically set by type from the test's ApplicationContext. However, if there are multiple instances of the property's type, it could be better to set the property by name. The Resource is used to mark test class properties which should be set by name from the test's ApplicationContext.

Transaction Management

With the declaration of a TransactionManager bean, and the use of the Transactional annotation, transaction boundaries are declarative and are automatically managed. Simply fire up the test and forget about whether or not your integration test changed the state of the database you're using to test.

The Transactional annotation is used within transactional Spring tests to mark test classes and methods which should have a transactional nature applied to them. When used to annotate a test class, a transaction context will be created before each test method is executed. After each test method, the transaction will be rolled-back. This will add the overhead of creating and managing a transaction for every test method in that class, so it is usually better to annotate the test methods with @Transactional instead. This will cause a similar effect to annotating the class, but only annotated test methods will be transactional. Usage of this annotation requires a TransactionManager named transactionManager to be defined in the test's ApplicationContext.

Similar in purpose to the Before and After annotations provided by JUnit, methods decorated with either the BeforeTransaction or AfterTransaction annotation will be run before/after any test method which is affected by the Transactional annotation (i.e. all methods in a class decorated with @Transactional, or each annotated test method when marked individually. Methods annotated with the BeforeTransaction or AfterTransaction annotations must be public and return no value.

Integration Test Helper Classes

When using the SpringJUnit4ClassRunner, you're given access to the ApplicationContext instance and a simplified interface for interacting with your integration test database through JdbcTemplate/SimpleJdbcTemplate.

spring-testing-sample.java

Testing Toolbelt: Groovy

Groovy, the apparent golden child of Java, is a mostly dynamic-typed JVM language which seeks to add functionality to the core Java language such that writing and testing code is much easier and requires less boiler-plate code. Some of the features provided by Groovy that I have found useful for testing are:

GroovyBean Properties and Constructors

Groovy attempts to simplify the usage of bean-type object by providing some shortcuts for accesses and assignments. By default, every class accessed through Groovy code is decorated with a default constructor which takes a map (property->value), and a getter and setter for each field defined in the class (for which there is not already a getter/setter). The constructor is a simple way to provide values to properties of the new instance.

properties-sample.groovy

Token Replacement

In Groovy, the String class is enhanced to allow for the use of tokens within a String literal. These tokens are of the form ${<property>} and will use the properties values available at the time of creation. Refer back to the above example to see some at work.

Collection Literals

Easily create a list by using the [] syntax, a range by using the <start>..<end> syntax, and a map by using the [<key>:<value>] syntax.

collection-sample.groovy

Closures

Closures are simply blocks of code surrounded by curly braces, which can be treated as reference types. Closures may declare arguments and may return values. Closures may be stored in variables.

closure-sample.groovy

Iteration (each)

Iteration of arrays, ranges, lists, and maps has been simplified by the addition of the each method.

each-sample.groovy

Coercion (Map and Closure)

Any map or closure may be interpreted as an instance of a specific type simply by using as <type>. This allows you to easily create stand-in objects, provided they have a public default (no-arg) constructor.

coercion-sample.groovy

GDK

Through the default meta-class implementations used by Groovy, many useful methods (many taking advantage of closures) have been added to the standard Java classes. There's too much to list here, but know that many of the above examples use GDK methods.

GroovyTestCase

The GroovyTestCase class contains a large portion of the testing functionality used by basic Groovy. Since the Groovy team have pledged backwards-compatibility with JDK 1.4, they have also stuck with the non-annotation-based version of JUnit(3.8.*) as a basis for their testing helper class. This is not as bad as it sounds, as many of the language features of Groovy make up for the missing capabilities of JUnit 4.4. Every test class defined using groovy must be a sub-class of GroovyTestCase. Each test method must be public, return void, and be named test<something>.

assert*

all of the assert* methods provided by JUnit are also present in the GroovyTestCase class.

shouldFail(<Throwable>)

similar to the Test annotation when used with the expected argument, the shouldFail method takes a Throwable class type and a closure, executes the closure, and fails if an instance of Throwable is not thrown within the closure.

shouldFail-sample.groovy

StubFor and MockFor

The StubFor/MockFor classes can be used within Groovy to create stand-in objects when coercion won't work or when you need to over-ride the behavior of a constructor.

stubfor-sample.groovy

References/Related:

• Programming Groovy: Dynamic Productivity for the Java Developer (Pragmatic Programmers)

Spring Note: SqlUpdate

The org.springframework.jdbc.object.SqlUpdate class is another tool that I use a lot. This class encapsulates INSERT, UPDATE, and DELETE queries as beans defined within your application context. In most situations, you will be using the SqlUpdate class as-is with multiple configurations within a DAO's context. Since the class is not abstract, it is quite easy to extend for creating dummy/mock instances for testing.

ITSpringJdbc.java

ITSpringJdbc-context.xml

New Group: Columbus Software Craftsmanship

As you may or may not know, I have two homes: SW Indiana, and Columbus, Ohio. Since I spend 75% or more of my time in SW Indiana and there are few opportunities in this area for networking/learning the craft, I'm always happy to learn about new groups of like-minded people in my other home.

I found this group through a random tweet from Marc Peabody. He mentioned that they would be trying out some Scala Koans and included a link to the group's Google Groups site. Since joining the group earlier today, I've found the details for the Scala Koans night and I've been informed of interest in running a Code Retreat event at the beginning of April in Columbus.

I haven't made it to any meetings yet (they're still a pretty new group), but I've had some friendly conversations in e-mail with members of the group and have met some of the other members through NFJS, COJUG, CRB, etc... Sounds like it should be a pretty good time when I'm able to make it.

Maven note: exec-maven-plugin

I'm currently working on a development package containing a series of .xsd files which will be used to define the external interface for our web service. Due to some other project constraints, it was decided that this package also needed to include the .wsdl files which will further define the web service.

I'm a lazy (the good kind) programmer, so I decided that I did not want to update these files every time the schema changed nor did I want to make anyone else figure it out later. I wrote a quick utility for creating the .wsdl files, based on the current .xsd files. Since we're already expecting to use Spring-WS for message dispatching, I wrote some file generation code around the org.springframework.ws.wsdl.wsdl11.DefaultWsdl11Definition class and wrote up a Spring configuration which put it all together.

My next task was to figure out a way to get this utility to run within the context of the Maven package phase. Since the code needed to generate the .wsdl files was the only code in this development package, it made sense to hook into the prepare-package phase instead of the generate-sources phase. Now that I knew when the utility should run, I just needed to figure out a way to do it. One Google search later, and I had the exec-maven-plugin. This Maven plugin provides two goals which can be hooked into arbitrary phases in the Maven life cycle:

• exec -- execute an arbitrary executable from within the Maven runtime
• java -- execute the main method, with arguments, of a specified class, from within the Maven runtime

So I set up my pom as shown below, and ran mvn package. The end result was a .jar file which contained both the .xsd and the .wsdl files we need. One mvn deploy later and these files were now available to all who needed them.

pom.xml

Testing Toolbelt: Hamcrest Matchers

The Hamcrest Matchers framework contains a series of Matcher classes which help implement comparison and assertion methods in a type-safe, declarative manner. When used in tests, the Matchers framework will produce more legible test code and more helpful failure messages. The Matchers framework is partially included in the JUnit 4.4 package and some portions can be used effectively. But, the full power of the framework can only be unleashed by including the real Hamcrest Matchers jar within your testing environment.

Matchers

The org.hamcrest.Matchers class in the Hamcrest framework provides a series of methods, intended to be used with import static, which supply various pre-defined org.hamcrest.core.Matcher instances.

• is -- The simplest matcher, most times behaves just as syntactical sugar around other matchers. But, if an instance of Class is passed, it behaves like the Matcher produced by instanceOf. If passed any other value, behaves like the Matcher produced by equalsTo. see org.hamcrest.core.Is
• equalTo -- Verifies that the test value is equal to the value used to instantiate the Matcher. see org.hamcrest.core.IsEqual
• instanceOf -- Verifies that the test value is assignable to the Class value used to instantiate the Matcher. see org.hamcrest.core.IsInstanceOf
• nullValue/nonNullValue -- Verifies that the test value is null-valued/not-null-valued. see org.hamcrest.core.IsNull
• startsWith/containsString/endsWith -- Verifies that the test value (String\-typed) begins with, contains, or ends with the value used to instatiate the Matcher. see org.hamcrest.core.StringStartsWith, org.hamcrest.core.StringContains, and org.hamcrest.core.StringEndsWith
• arrayWithSize/emptyArray/hasSize/empty -- Verifies that the test value is an array/collection that either has the given number of elements/is empty. see org.hamcrest.core.IsArrayWithSize, org.hamcrest.core.IsCollectionWithSize, and org.hamcrest.core.IsEmptyCollection
• lessThan/lessThanOrEqualTo/greaterThanOrEqualTo/greaterThan -- Verifies that the test value is strictly less than/less than/greater than/strictly greater than the provided value. see org.hamcrest.core.OrderingComparison

Examples