fest-481 : Assert.isIn() and isNotIn() should take Iterable<?>

[nfrancois]

See http://jira.codehaus.org/browse/FEST-481

[ash2k]

Great! Idea - why not make those methods even more type-safe (like isIn(A... values)) by using Iterable<? extends A>?
Actually, it seems like alot of places can be type-safer in this great library. It will give us compile time checks (instead of failing test at runtime because we passed wrong iterable instance) and more correct IDE autocompletion.

[nfrancois]

@ash2k could be interesting.
Seem working on my computer, but before pushing, I prefer have a idea about on what can be more be easily writed with.
Did you got a example on what is painfull to write the Iterable<?> and become easy with Iterable<? extends A> ?

[joel-costigliola]

@ash2k I agree with Nicolas, it would be nice to have a concrete example (that we could use for unit testing).

Thanks !

[ash2k]

This can't be used as a unit test but it shows benefits of generics:

public class Test1 {

    private final A var1 = new A();
    private final B var2 = new B();

    public void a() {
        Collection<B> colB = codeUnderTest();

        // wanted to write
        // Assertions.assertThat(var2).isNotIn(colB);
        Assertions.assertThat(var1).isNotIn(colB);
    }

    public Collection<B> codeUnderTest() {
        // broken logic. should be
        // return new ArrayList<B>(Arrays.asList(new B()));
        return new ArrayList<B>(Arrays.asList(var2));
    }

    public class A {
    }

    public class B {
    }
}

With current implementation (wildcards instead of captured types) this broken test will compile and pass not detecting the error in codeUnderTest(). If ObjectAssert is modified to be parametrized with type A the test will not compile and Eclipse is showing error

The method isNotIn(Test1.A...) in the type AbstractAssert<ObjectAssert<Test1.A>,Test1.A> is not applicable for the arguments (Collection<Test1.B>)

Java is a staticly typed language and generics were added to provide means to do more strict compile-time type checking. I think the question is "Why not use them?" than "Why use them?".

What do you think?

[nfrancois]

@ash2k thanks your example. It's true check if a element is/is not in different type list, it does not make sense.

I try to write :

assertThat(frodo).isNotIn(ringsOfPower);

Should not compile, but it compile just because type of A is Object.
I think I must be ok with #11

[joel-costigliola]

I think we should go as Mikhail suggest.

[joel-costigliola]

Nicolas,
I'm would like to release Fest Assert 2.0M3 this week end, it would be nice to include fest-481 fix.
Will you have time to finish it with Mikhail suggestion ?
If you don't, there is no problem, I will do it.

Cheers,

Joel

[nfrancois]

I have already pushed this suggestion in this commit :

https://github.com/nfrancois/fest-assert-2.x/commit/18ac8197505121ad8962738ebb7f9bf973a1ac7a

Could be some conflict with #11, I let you see

[joel-costigliola]

Ok, my bad, did not see your commit.

Thanks !