commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Kestle <stephen.kes...@orionhealth.com>
Subject [collections] VOTE: Rewriting junit tests (Was: Test cases for compilation failures on generifying collections.)
Date Sun, 18 Mar 2007 20:34:17 GMT
Ok - the problem is that the end of the test is performing a type safety 
check.  Something that the generic parameters will not allow.  The 
collection under test should contain Collections of Strings, not Strings 
- that's the same as the closure.  Therefore it's a compile error to add 
a string to the collection.

But apart from that - WHAT IS THAT TEST DOING???!!!  It's absolutely 
horrible.  It has no place in that class.  (Sorry guys, I just hadn't 
looked at the tests for Commons Collections before this).
This is why mock object libraries were created - to ensure that the 
method under test is the method under test.  When testing 
CollectionUtils, we have no business using reflective Closure 
implementations, and then testing the bounds of those to ensure they 
work correctly.

If I were to write that test:

Closure<Number> testClosure = EasyMock.createMock(Closure.class);
Iterable<Long> col = new ArrayList<Long>();
col.add(1);
col.add(2);
testClosure.execute(1);  //Record the expectation that '1' will be processed
testClosure.execute(2);  //Record the expectation that '2' will be processed
EasyMock.replay(testClosure);
CollectionUtils.forAllDo(col, testClosure);
EasyMock.verify(testClosure);

There - less than half the lines, clear about what it's testing, won't 
break in the future, unless the method under test breaks, etc, etc.
If we were to go ahead with proxied mock based testing (which I would 
strongly recommend), then I have a (IMHO) really good helper test class 
for making it even easier than above, and I'd be able to show the really 
correct way of doing it, without being too much more verbose - lines 2-4 
should be something like:

Iterator<Long> iterator = EasyMock.createMock(Iterator.class);
Iterable<Long> col= EasyMock.createMock(Iterable.class);
EasyMock.expect(col.iterator()).andReturn(iterator);
EasyMock.expect(iterator.next()).andReturn(1);
EasyMock.expect(iterator.next()).andReturn(2);

This would set up the exact way that we want CollectionUtils methods to 
work (which is what we want in THIS case), and would be extracted to a 
separate iterableSetUp() method.

So, can we import EasyMock as well as Junit4?  Our tests should be far 
more like deterministic mathematical proofs than they are at the moment.



Stephen Smith wrote:
> Hi,
>
> Does anyone have any example JUnit 3.x test cases for testing 
> compilation failures on generifying collections?
>
> For example, the end of the current test case 
> TestCollectionUtils#testForAllDo asserts that adding invoking 
> CollectionUtils#forAllDo(Collection c, Closure cl) fails when cl is 
> defined to accept Collection and c is defined to contain Strings. 
> After generifying CollectionUtils#forAllDo(Collection<T> c, Closure<T> 
> cl), the test case will no longer compile and I'd prefer to replace it 
> with a JSE5 compatible assertion rather than delete it - does anyone 
> have any thoughts on this?
>
> Steve.


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message