MIT is compatible.
Raise JIRA calls for everything for now.
Stephen
Stephen Kestle wrote:
Is the MIT license compatible? I'm struggling to figure out whether it
is or not...
If it is, I'd like to have a go at revamping the CollectionUtils test
with something more... concise (and tell, not ask). Should I create a
ticket to include this jar etc, or email straight to you?
Cheers
Stephen
Stephen Colebourne wrote:
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]
---------------------------------------------------------------------
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]
