Consider AbstractAssert.is(Predicate)

[Lugribossk]

Consider adding overloaded has()/is() methods to AbstractAssert that apply a com.google.common.base.Predicate. This will make it easier to write fluent tests for codebases that already use Predicates, without having to create Conditions or custom AbstractAssert subclasses.

Example:

public enum Color implements Predicate<Square> {
    BLACK,
    WHITE;

    // Already used elsewhere in the code.
    @Override
    public boolean apply(Square square) {
        return square.hasColor() && square.getColor() == this;
    }
}

public class Square {
    //...

    public boolean hasColor() {
        //...
    }

    public Color getColor() {
        //...
    }
}

public class SquareTest {
    @Test
    public void testDefaultColor {
        // No SquareAssert.isColor() needed
        Square s = new Square();
        assertThat(s).is(Color.WHITE);
    }
}

Unfortunately this will mean a dependency on Google Guava.

[ansgarkonermann]

I understand your desire to use existing predicates with FEST-Assert. From a user's perspective, this is convenient, and I generally support requests to make FEST-Assert convenient to use.

OTOH, if we simply add Guava as a dependency, FEST-Assert will over time become the "Dependency Magnet of the Universe (TM)". So before we implement anything depending on Guava, or Joda Time or Hibernate, or GWT, ... we should think hard how we can handle this proliferation of dependencies.

For example, I specifically don't want to force FEST-Assert users to pull Hibernate into their test classpath, just because FEST-Assert does support some database-related testing.

Tobias Gesellchen (AKA gesellix) is working on some "modularisation" efforts to allow extension of FEST-Assert, even if this means more dependencies, while at the same time not forcing these dependencies on any user of FEST. See http://jira.codehaus.org/browse/FEST-485 for details and maybe join the discussion.