0

In hamcrest (1.3.RC2, with no JUnit dependencies) I am failing using iterableWithSize() with a SpringDataNeo4j library.

I have an (extension of) an Iterator parameterized with Content like this 

EndResult<Content> contents = contentRepository.findAllByPropertyValue("title", "*");

where EndResult is

package org.springframework.data.neo4j.conversion; public interface EndResult extends Iterable {...}

and Content is a a @NodeEntity Pojo.

With the help of Mark Peters I learned that I should call it like this 

assertThat(contents, IsIterableWithSize.<Content>iterableWithSize(2));

since iterableWithSize is typed on the component type of your Iterable, not the concrete type of iterable itself.

But when test is run I get 

java.lang.AssertionError: Expected: 
an iterable with size <2> 
got: org.springframework.data.neo4j.conversion.QueryResultBuilder$1@1970ae0

Trying to figure out whether either 1) I am doing some thing wrong, or 2) hamcrest or 3) Spring Data Neo4j has an bug, I checked my object at hand, and it seems OK as an Iterable :

 public static int iterSize(Iterator iter){     
    int i=0;                        
    while (iter.hasNext()){ i++;iter.next();}                       
    return i; 
 }
 public static int iterSize(Iterable iter) {return iterSize(iter.iterator());}

 assertEquals("contents contain 2 items", 2, iterSize(contents)); // works OK

So I guess it possibly concludes that its hamcrest that has a problem. Has anyone tried anything similar with IsIterableWithSize ?

The test code is https://github.com/anodynos/SpringDataNeo4jTrials/blob/master/src/test/java/sdnTests/test/HamcrestIteratorSizeTest.java

Community
  • 1
  • 1
Angelos Pikoulas
  • 1,002
  • 1
  • 14
  • 21
  • I don't understand; in your hamcrest assertion you expect an `Iterable` with size 1 but in your normal JUnit assertion you expect an `Iterable` with size 2, so of course one will fail. If you want help you need to post an example that actually demonstrates the problem (ideally reproduced without Spring if possible, as that narrows down the problem). See http://sscce.org. – Mark Peters Mar 15 '12 at 21:06
  • @Mark, the size of the Iterable I pass is not the issue here - obviously it fails the same way with either 1, 2 or any other int with `java.lang.AssertionError: Expected: an iterable with size <1> got: ` – Angelos Pikoulas Mar 15 '12 at 22:14
  • 1
    No, what is at issue is that you are expecting help without giving a clear example of the problem. Give us a compilable, self-contained piece of code that demonstrates the problem. That's your due diligence. And you're past the generic issue, so rename and edit your post since this has nothing to do with that. – Mark Peters Mar 15 '12 at 22:15
  • Thank you Mark - I was going to post a complete sscce, but I found the problem to be related to the description hamcrest gives when IsIterableWithSize fails, due the size test : it just gives a misleading message (the part after "got:"). When you pass the correct number of items it expects, the test passes. – Angelos Pikoulas Mar 16 '12 at 00:54
  • @Mark, as you suggested I have added the test code https://github.com/anodynos/SpringDataNeo4jTrials/blob/master/src/test/java/sdnTests/test/HamcrestIteratorSizeTest.java – Angelos Pikoulas Mar 23 '12 at 21:09
  • That code doesn't compile, please try again. – Mark Peters Mar 24 '12 at 04:31
  • Oh, you're just wondering about the description? Hamcrest always uses the `toString()` method of the "got" object for the "got" part of the description. So whatever class `QueryBuilderResult$1` is (the first anonymous inner class of `QueryBuilderResult`) just isn't overriding `toString()`. It's just a step neoj should take but hasn't (you should almost always override `toString` for data classes). There's nothing Hamcrest can do about this. The matchers are consulted for the expected portion of the description only, and it's not too difficult to reason why. – Mark Peters Mar 24 '12 at 04:32
  • Thanks - I think its maybe cause hamcrest matcher has not implemented the describeMismatch() method yet. – Angelos Pikoulas Apr 02 '12 at 15:41

1 Answers1

1

You are seeing this less helpful message because you are using JUnit's version of assertThat. If you use the assertThat provided with hamcrest it is able to better describe the mismatch.

Replace

import static org.junit.Assert.assertThat;

with

import static org.hamcrest.MatcherAssert.assertThat;
andygavin
  • 2,784
  • 22
  • 32