The collections tests were probably written before the concept of mocks
became widely known. I have no problems with the use of mocks for
testing in collections, provided that the license of the tool used is
compatible with Apache Software Foundation restrictions (no GPL or LGPL).
Stephen
Stephen Kestle wrote:
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]