The presenter is John Ferguson Smart who runs testing and agile tools bootcamps around Australia and NZ (as well as elsewhere) so if you are in the vacinity you should consider looking into em.

My notes from the presentation:

Naming tests

Dont use the name testXXX – you aren’t testing methods of your code

You are testing use cases – what should your class be doing

Take out private methods, maybe extract to a separate class and test those separately if they are getting too big.

Use the word should.  Express an outcome

Class Name: When is a behaviour applicable
Method Name: When at is the behaviour testing

Tests become more readable.

Arrange-Act-Assert

Create the test collaborators – Inputs and Expected Outputs (Arrange)

Test the behaviour (Act)

Verify behaviour is correct (Assert)

Extending Hamcrest Matchers

Combine matchers together – hasItem(someOtherHasPropertyMatcherYouPreviouslyDefined)

Create a new matcher –

1. Extend TypeSafeMatcher<type of thing you are checking against)
2. Implement Constructor take in  a matcher of expected value
3. Implement matchesSafely(type of thing you are checking against)
4. Implement describeTo – decorate the existing test result/matcher description…  description.appendText(“WuzUp!”); matcher.describeTo(Description);
5. Create a Factory Class for your matchers with static factory methods to return a new matcher
6. Use It

Multiple asserts per test are bad (see also Integration Tests are a Scam)

You can combine hamcrest matchers into one test

assertThat(itesm, allOf(hasSize(1), hasItem(“java”)));

assertThat(itesm, hasSize(greaterThan(1)));

The error messages will be cleaner too – expect list size of one, and has item java but received <blah>

Parameterized Tests

Usually just one test per Parameterized test class – they get run once

Ways to get test data

Use an xls spreadsheet source

Use Selenium 2’s WebElement to get a webpage

@FindBy(name="HD_EN") WebElement importerName;

@FindBy(name="HD_EA") WebElement importerAddress;

@FindBy(name="HD_ER") WebElement importerRepresentative;

// getters and setters

 // getter return importerName.getValue();

// setter
public void setImporterName(String value) {

     enter(value, into(importerName));

}

Smoke test to make sure getters and setters are correct

Make sure the annotations aren’t wrong

JUnit Rules

Delete folders after test run

@Rule public TemporaryFolder folder = new TemporaryFolder()

folder.newFile(“a file name”);

ErrorCollection,

accumulate errors rather than fail on first.  This saves having to write 20 different tests with large setup that check 20 things on the same page (eg login and load webpage table then verify each cell)

@Rule public ErrorCollector collector = new ErrorCollector();

// in your test

 collector.addError(new Throwable(“blah”));

collector.addError(new Throwable(“something else”));

collector.checkThat(result, yourMatcher);

The result will show “blah”, “something else” and the result of your failed matcher, as well as fail the test.

TimeoutRules

When you know something should have a short response time, a DAO for example should be shorter than 1 second

@Rule public MethodRule globalTimeout = new Timeout(1000);

@Test public void catchInfiniteLoopInTest() { for(;;); }

Catch any major issues before they get into production and become embarassing

Verifier Rule

Something that happens after a test is completed, like an assert

Inject behaviour to make JUnit add checks after each test…. kind of like a test post-condition or invariant from Betrand Meyers OO Software construction, but just for the tests themselves.

private List<String> systemErrorMessages = new ArrayList<String>();

@Rule

public MethodRule verifier = new Verifier() {

    @Override

    public void verify() {

        assertThat(systemErrorMessages.size(), is(0));

    }};

A good example I see would be using it to tie up mock verification calls in EasyMock

Watchman Rule

Called when a test fails or succeeds.  Additional logging perhaps?  How about restarting a GUI, or take a screenshot when a test fails.

Categories

Group tests in your own hierarchy based on your classification of the test rather than writing test suites.  Performance tests  that integration tests.  Slow running or fast running tests?

You can setup plain old normal interfaces for your categories, and have them extend each other via subclassing.  There is no Junit annotation here to indicate its an interface for testing, so you can potentially use any interface in your source.  I’m not sure if this is good practice or not, but say you wanted all your DAO tests that implemented a GenericDAO to be tested, you could do this…. or how about test all classes that implements Serializable?

You can annotate a test class, or tests methods with @Category(InterfaceName.class)

When running a category suite however you still need to include the classes to inspect as well as the category name.

@RunWith(Categories.class)

@IncludeCategory(PerformanceTests.class)

@SuiteClasses( { CellTest.class, WhenYouCreateANewUniverse.class })

public class PerformanceTestSuite {}

@RunWith(Categories.class)

@ExcludeCategory(PerformanceTests.class)

@SuiteClasses( { CellTest.class, WhenYouCreateANewUniverse.class })

public class PerformanceTestSuite {}

But how about scanning your whole test bed?  Can we programmatically inject suite classes and use them with Categories?  At this point it is a limitation unless you want to use a classpath hack.

Parallel Tests

If you have fast IO and multicore (like my new work PC ) and well written tests that don’t trodd on each others data.

U use Maven’s surefire 2.5 plugin to achieve this, and say methods, classes or both in parallel.  Classes is probably safer since most people write the test slipping thru later tests in the same class depend on earlier test methods accidentally.

Infinitest

This is a tool for IntelliJ and Eclipse that runs tests when you save your source and tells you if you have failed runs.  I remember twittering about how cool this would be if it existed a while back, and I’m glad I wasnt the only one with this idea and that someone actually implemented it .

Also there was a plugin for IntelliJ called Fireworks but I could never get it to run tests properly on my Windows PC; always complaining about not being able to find a JDK home .

This tool seems pretty cheap at $29 for an individual license, I’ll check it out and give it a shot.

http://improvingworks.com/products/infinitest/

What would be super cool is if it worked with Categories mentioned above, to be able to exclude GUI tests from being executed.  There may be a feature in Infinitest that handles it but I’d be keen to see.

Mockito

I’m traditionally an EasyMock guy but Mockito has always had good buzz.  At my new job we dont actually have a mocking framework yet so I’m keen to give it a look.

Mockito seems to have less verbose setup of tests, something that when learning EasyMock bashed me around a bit – ever forget to get out of record mode and get a green test accidentally.

As per Integration Tests are a scam ypresso recommends, you can verify interactions, verify a method is being called with certain params.

Other Stuff (comments from the Q&A of the presso)

Hibernate mappings – use an in-memory database

FEST asserts – an alternate to Hamcrest that avoids the Generic issues that plague Hamcrest!!! (boy this frustrates me a lot as a Hamcrest user)

Cobertura – a code coverage tool, alternate to Emma

Private methods shouldn’t be tested explicitly – you should be able to sufficiently test a class by its public facing API.

Integration Tests are a Scam by Joe Rainsberger

This was my favourite presentation from last year. It talks about writing the correct type of unit tests to get get fast results and reduce the need for slower integration tests that are generally slower are require a lot of maintenance. He makes a compelling argument about the number of tests in your system don’t improve the sense of security you get from your tests by the same amount. So he talks about what needs to be unit tested from the contract class and the opposite collaborator class and how doing so gives you a better picture of what tests you need to give you a sense of security with quick feedback. The blurb explains it better

Integration tests are a scam. You’re probably writing 2-5% of the integration tests you need to test thoroughly. You’re probably duplicating unit tests all over the place. Your integration tests probably duplicate each other all over the place. When an integration test fails, who knows what’s broken? Learn the two-pronged attack that solves the problem: collaboration tests and contract tests.

TDD of Asynchronous Systems

This presentation by the author of a new book, “growing object oriented software, guided by tests” Nat Pryce, which talks about testing at the integration/functional level and techniques to get around all the painful ‘flickering tests’ & ‘false positives’ issues that occur when you have them. The examples talk about testing legacy systems, swing gui’s and JMS queues.

One of the key ideas is that one must find a point to synchronise on before executing the assertions and those assertions must wait (and retry if not true) until the state has changed or a timeout occurs (and the test then fails)

As a user of UISpec4j with its Assertions that have a timeout, and some perilious test code when someone innocently mixed junit assertions with a UI test, I could relate to this really well.

Theories offer a sound alternate, specifying a single test method, with a different set of annotations to the regular @Test defining a field or annotation based ParameterSupplier to inject a series of values into each test.

Schauderhaft’s blog provides a great summary of what theories are and how to write a parameter supplier to supply a series of datapoints in Java. The annotation based ParameterSupplier does look a little verbose but as Schauderhaft points out, they can be reused – annotation based data fixtures – excellent. I liked these two posts because they do a better job at explaining than the release notes. The blog also links to a blog about another Junit4 feature – parameterised tests – that seem to be a precursor to Theories, and a little simpler to setup. Another great source of how to use Theories is actually in the Groovy documentation about Junit integration. Closures make Datapoints a little more concise (or maybe the example is just simpler? hehe) along with the fact that test data (lists,maps) have a groovy conciseness to them to begin with.

A very good UML diagram reference (I may have referenced this one before).

http://www.agilemodeling.com/essays/umlDiagrams.htm

And a page of useful agile resources, from a process standpoint.

http://www.agilelogic.com/sp_resources.html

I particularly like the ones about Missing the Point of the Daily Stand-Up? and eXtreme Adoption eXperiences of a B2B Start Up

The Self-Shunt unit testing pattern in short is a way to think about your tests so that you are not testing more than one thing in a test. It talks about passing the object you are testing to itself. Here is a quote (paraphrased) from the document about when to use it "Methods such as testScanAndDisplay scream testing two things."

Usage:
assertThat(“You Failed”, testValue, allOff(greaterThan(3), lessThan(6))

They seem a lot simpler in this context even though they are the same thing.

The Matchers are taken from a project called Hamcrest which both JUnit, various xMock and other testing frameworks have all jumped on board to.

Hamcrest comes with a library of useful matchers. Here are some of the most important ones.

• Core
  • anything – always matches, useful if you don’t care what the object under test is
  • describedAs – decorator to adding custom failure description
  • is – decorator to improve readability – see “Sugar”, below
• Logical
  • allOf – matches if all matchers match, short circuits (like Java &&)
  • anyOf – matches if any matchers match, short circuits (like Java ||)
  • not – matches if the wrapped matcher doesn’t match and vice versa
• Object
  • equalTo – test object equality using Object.equals
  • hasToString – test Object.toString
  • instanceOf, isCompatibleType – test type
  • notNullValue, nullValue – test for null
  • sameInstance – test object identity
• Beans
  • hasProperty – test JavaBeans properties
• Collections
  • array – test an array’s elements against an array of matchers
  • hasEntry, hasKey, hasValue – test a map contains an entry, key or value
  • hasItem, hasItems – test a collection contains elements
  • hasItemInArray – test an array contains an element
• Number
  • closeTo – test floating point values are close to a given value
  • greaterThan, greaterThanOrEqualTo, lessThan, lessThanOrEqualTo – test ordering
• Text
  • equalToIgnoringCase – test string equality ignoring case
  • equalToIgnoringWhiteSpace – test string equality ignoring differences in runs of whitespace
  • containsString, endsWith, startsWith – test string matching

Here is a summary of Matchers from the Hamcrest tutorial page.  They may not all be in JUnit.  JUnit ships with org.hamcrest.CoreMatchers and org.junit.matchers.JUnitMatchers.

Assumptions

Assumptions are like @Ignore-ing tests programmatically.  They are a test, intended to determine that the environment a test is running in, will successfully run the test.  The example from the JUnit 4.4 release notes best illustrates this:

import static org.junit.Assume.*  

@Test public void filenameIncludesUsername() {
assumeThat(File.separatorChar, is('/'));
assertThat(new User("optimus").configFileName(),
is("configfiles/optimus.cfg"));
}

If the expression in the assume statement fails, then the test will be marked as passed.  Apparently in future, the failed assumption may lead to the test being marked as ignored which would be excellent.

Edit: Another useful resource is the Junit API on Matchers

Encouraging the business to get involved at an early stage means that the business refine their requirements further.

Fit Tests can tell us useful things.  Where a FIT test fails, its an indicator that we need more code to cover business requirements.

Fit complements xUnit, the fixtures are similar but the test data, state and structure is all defined in the business supplied doco’s.  The fixtures are simply glue from these documents to the tests.

Automating Business Value with FIT and Fitnesse from InfoQ

Fit: Framework for Integrated Test

And when regular XP wont do, get Industrial XP.  Nothing to do with FIT, just a site mentioned in the first link.

Given that in Eclipse, I’m told in almost realtime where compilation errors occur as I write them, and how this acheives high build success rate, I wonder if Eclipse can precompile and debug JUnit tests so that as we are changing code that is used in a test class, the test runs and the results are fed back in almost realtime, allowing us to pickup on even more potential hazards.

Lots of pitfalls for the cynical but its so crazy it just may work.

Ok, I was a bit nieve, its more aiken to the Object Spy of QTP, allowing to see the heirachy of a Java object just by clicking it.

The neatest thing it has though is a Player to help diagnose the drawing an layout of your objects.  I thought this was a player, ala QTP recording and playback, but no, its a different kind but still very useful if you are trying to debug layout in a Swing app.

http://www.froglogic.com/pg?id=Products&category=squish&sub=editions&subsub=java

And when you want to change all your vbscript scripts to JavaScript, you could use this