The test needs to perform a check that the result of transforming some xml is correct.  A reference file is available so we can use XMLUnit to perform a difference.  In my file there is a seconds attribute and because seconds vary with each parse we choose to ignore the value.  There are other ways to achieve this, but its more complex and uses more XMLUnit code. Using a google predicate simplifies this check.

First produce your output file and load the sample and output into strings. Normally for a test I produce a smaller sample xml file. Then using XMLUnit difference engine get all differences.

    Diff d = new Diff(expectedAsString, outputAsString);
    DetailedDiff dd = new DetailedDiff(d);
    List listOfDifferences = dd.getAllDifferences();

Next call a function to check that the only differences found are within the seconds attribute. This uses a predicates from google to perform the matching.

    assertTrue(onlyDiffsMatchThisAttributeName("seconds",listOfDifferences));
    }

    private static boolean onlyDiffsMatchThisAttributeName(final String attrName, Iterable it) {

    Iterable filtered = Iterables.filter(it, new Predicate() {

        @Override
        public boolean apply(Difference input) {

                final NodeDetail testNodeDetail = input.getTestNodeDetail();
                if (nodeDetail == null) return false;

                final Node node = nodeDetail.getNode();
                if (node == null) return false;

                final String nodeName = node.getNodeName();
                if (nodeName == null) return false;

                return !nodeName.equals(attrName);
            }
        });
        return (newArrayList(filtered).isEmpty());
    }

Note that what is happening here is the predicate is filtering away all the seconds matches. If anything remains in the list false is returned. Neat huh!

                          

Be careful to check that your objects are consistent with equals though.  I have mentioned this before.

In the following method I am using the Objects.equal with a BigDecimal class.  It does not work because BigDecimal equals treats 0 and 0.0 as not equal, which is probably not what you need.

public boolean equals(Object obj) {
    if (obj == null) {
      return false;
    }
    if (getClass() != obj.getClass()) {
      return false;
    }

    final TestEquals other = (TestEquals) obj;

    return Objects.equal(this.bigDecimal, other);
}

The common solution is to use the compareTo method instead like so.

  final TestEquals other = (TestEquals) obj;
  if (this.bigDecimal != other.bigDecimal &&
      (this.bigDecimal == null
      || this.bigDecimal.compareTo(other.bigDecimal) != 0)) {
    return false;
  }
  return true;

I will be using this technique, especially where the object has many attributes but I will be testing the equals method.

                          

Typical Eclipse template for Google Collections

${:importStatic(com.google.common.collect.Lists.newArrayList)}newArrayList();
${cursor}
${:importStatic(com.google.common.collect.Sets.newHashSet)}newHashSet();
${cursor}

To use them, just open Eclipse Preferences: Java Editor: Templates.  Add new templates, and give them a name similar to the method.  I.e newArrayList.  Then your code completion hot key will run the template completing the text your typing in.  i.e you type newArrayList [code complete key] and it adds the static, and the rest of the method, placing your cursor at the end of the line.  Neat!

Note: See the comment from Yuri below, the above templates are no longer required for static imports. Its possible to configure the Content Assist to bring in a whole type, or member using Prefs:Java:Editor:Content Assist:Favorites. This is better as it scans all possible available methods in the type.

The code you end up with is tidy too:

List myList = newArrayList();

There is another thing I can never remember the syntax for!   The markup to add the syntax highlight for this blog. Available as a gist: http://gist.github.com/234709

                          

Take a look at this interface.  If I find this populate method, I am likely to have to open implementations.  I don’t know if it populates one map from the other or both maps.

import java.util.Map;

public interface NastyPopulator {

void populate(Map<String, String> driver, Map<String, String> driverHolder);

}

The problem is the semantics of map are that you can read from maps or you can write to them.  I think this is a slightly better approach below.

I have used ImmutableMap.Builder.  The semantics of this are that it is used to build things.  I will call build() on the object later to get a map.  Next its an ImmutableMap.  So not only am I declaring that the two parameters are likely to be used to build something, that thing will ultimately be Immutable so in effect the signature declares that I am not expected to make modifications later.  Finally the method name is unambiguous buildMaps, which pretty much says what its going to do.

import com.google.common.collect.ImmutableMap;

public interface LessNastyPopulator {

void buildMaps(ImmutableMap.Builder<String, String>  driver, ImmutableMap.Builder<String, String> driverHolder);

}

Feels like a stronger declaration to me. If ImmutableMap is awkward you could define your own static builder and pass that in, at least your still declaring up front, that this method is builds the two maps. If the method is reading from one map and building others, how about passing an iterator and a builder?

                          

The thing that interests me is peoples response to innovation.  It takes time for people to work out how to use new systems like this.  The more flexible it is the longer it takes people to blend a culture around it.  Wave does remind me somewhat of having my first phone that could send a text, and only having one other friend with a similar phone and the will to use it.  Lets hope google get the bugs and interface ironed out soon though as I think its going to be a fun way to colaborate.

                          

But the devil is in the detail so here it is anyway.

I have this multi threaded application. One of the problems with integration testing it is, you can’t guarantee the order that messages will be written to a stream. So during the test I have to go to some trouble to split and order the lines written out. If I don’t do this the test fails sometimes. It depends on which thread writes first. The output though is correct, order is not important. Not exactly rocket science.

Here is the method I was using to massage the string.

 public List<String> getSortedLines(String expectedString) {

        String[] splitExpectedResultLines = expectedString.toString().split("\n");
        List<String> resultLines = new ArrayList<String>();
        for (String messageLine : resultLines) {
            resultLines.add(messageLine);
        }

        Collections.sort(resultLines);
        return resultLines;
    }

There is nothing particularly wrong with the method. It takes a string, splits it into lines, loads a List, sorts and returns it. Thus when its used in an assertion later the expected and actual lists are the same.

With google collections its just three lines! The HashMultiset is designed to be used in equals methods. Its equal even if the order of the elements in collections being compared is different. From the API documentation: An extension of Collection that may contain duplicate values like a List, yet has order-independent equality like a Set. One typical use for a multiset is to represent a histogram.

Its possible to use the HashMultiSet.create static factory method, passing in an Iterable. i.e a Collection. So from the original code, both the loop and the Collections.sort are no longer required.

   public HashMultiset<String> getOrderAgnosticCollection(String expectedString) {

        String[] splitExpectedResultLines = expectedString.toString().split("\n");
        Iterable<String> resultLines = Arrays.asList(splitExpectedResultLines);
        HashMultiset<String> orderAgnosticResultLines =
                                              HashMultiset.create(resultLines);

        return orderAgnosticResultLines;
    }

If there was something that performed the split, but returned an Iterable the method would be perfect!

                          

Steps taken to refactor

There was actually very little to do.

Step 1, add a maven dependency

            com.google.collections
            google-collections
            1.0-rc3
            jar

Step 2, replace the array with an ImmutableList

private static final LineResult[] EMPTY_LINERESULT_ARRAY = new LineResult[0];
private LineResult[] lineResults = EMPTY_LINERESULT_ARRAY;

could become:

private List<LineResult>  lineResults = ImmutableList.of();

In the end I used ImmutableList to clearly my intent. The usage is internal to the class so there is no advantage in using the List interface.

private ImmutableListst<LineResult>  lineResults = ImmutableList.of();

Step 3, The constructor and static factory methods are simplified
We are no longer using an array to back the list, so the protective copy can be moved from the constructor into the static method. This reduces the window of vulnerability you are exposed to before capturing the data held in the list. This is a direct result of the google class providing a static factory method. Nb. Its a shame that the standard collections don’t provide static factory methods.

Prior to the changes the protective copy was done in construction like this.

 this.lineResults = lineResults.toArray(EMPTY_LINERESULT_ARRAY);

This result is a much simpler constructor.

private ResultsFileSearch(File fileFound, ImmutableList<LineResult> lineResults) {
        this(fileFound);
        this.lineResults = lineResults;
}

My newInstance method makes use of the ImmutableList.copyOf static factory method resulting in a very clean conversion of List into Immutable list. Note that generics is inferring the type.

public static ResultsFileSearch newInstance(File fileFound
                 , List<LineResult> lineResults) {
        return new ResultsFileSearch(fileFound
                        ,ImmutableList.copyOf(lineResults));
}

Step 4, the getLineResults method no longer has to deal with the array or conversion.
The original array backed object had to deal with returning either an empty list or conversion to an unmodifiable list. There are two things I did not like about this when I wrote the original.

• The code has to check the array resulting in some conditional logic. This increases the test overhead slightly.
• The use of Collections.unmodifiableList(Arrays.asList(lineResults)); is very ugly and slow.

This was the original, note the subtle bug when returning an empty list.

 public List<LineResult> getLineResults() {

        if ((this.lineResults.length == 0)) {
            return Collections.emptyList();
        } else {
            return Collections.unmodifiableList(Arrays.asList(lineResults));
        }
        return this.lineResults;
}

I hope you agree its a much simpler version using the google code. As we are now using the Immutable implementation, we don’t have to worry about exposing the reference.

public List<LineResult> getLineResults() {
        return this.lineResults;
}

Conclusions

Using the google collections makes my implementation much cleaner. Several complexities are given over to the google collections classes. Moreover testing of my class is simpler. The changes are contained within the class. None of the method signatures change, which has two consequences. On the plus side the re-factor is contained within this class. On the negative side, any code modifying the list will raise an UnsupportedOperationException which was no different to my original version. The construction of my class might be slightly slower, the memory overhead slightly bigger now that we are not using the array. Counter to this, the getLineResults method is quicker as it now only returns a reference. In my program this is more important as architecturally it uses bounded queues to hold these objects for processing by threads. So although its using a little extra memory, its constrained. The performance gain is worth it.

I recommend using the com.google.common.collect package but adhere to the caveats i.e don’t expose the types in an API etc.