Overview

Performance tuning an application is time consuming, and expensive. Useful tests often need dedicated hardware to run on. It's specialised and time consuming to prepare the ground work and write the various fixtures needed to run, and whose only perceived benefit is preventing a production issue that you don't even know will happen yet.

Stereotypical Scenarios and Outcomes

Here's some stereotypes I've encountered:

Here's a few tips on how take make testing your code for logical correctness (as opposed to multi-threaded correctness).

I find that there are essentially two stereotypical patterns with threaded code:

Be "realistic":

Document supporting code:

1. Test doubles or fixtures won't be reused if people don't know about them or how.

With JUnit, consider using @Rules to provide mixin-esq components for tests.

Prefer fakes:

Tests should be fast to run and fast to write:

Chose a system that has a low barrier to entry, something people are keen to learn, or will already know:

I love automated testing. In a rare diversion into op-ed¹ I thought a put few thoughts (read - opinions) together.

Before I start on how best to compose your tests, I briefly ask - What are the reasons for testing? Broadly, I think they are:

This is a 5 minute tutorial on how to write a test story using EasyB, a Groovy based behaviour driven development system for Java.

You'll need Maven installed and you may want to have an IDE with Maven and Groovy integration. Additionally, both IntelliJ and Eclipse also provide EasyB plugins that allow you to run individual stories.

Firstly create a skeleton project, and add these plugins to your POM:

A first draft of a JUnit @Rule that create the test context. This can be used with the Spring context rule for this post to create a complete Spring context for integration tests.