Custom hamcrest matcher that works with "not"?

Question

I have some class (say, Entity).

I want to be able to

1. test that an instance of that is "valid", using some custom code to decide that
2. also test that an instance is not valid, ideally using the same code.

Using maven, surefire, JUnit 4.11 (and the hamcrest stuff shipped with it).

So I write a class something like this

class IsValidEntity extends TypeSafeMatcher<Entity>{

    @Override public boolean matchesSafely(Entity e){
       // and here I do a bunch of asserts...
       assertNotNull(e.id);
       // etc.
    }

    @Override
    public void describeTo(Description description) {
       description.appendText("is valid entity");
    }

    @Factory
    public static <T> Matcher<Entity> validEntity() {
        return new IsValidEntity();
    } 
}

OK, fine, I can then do

assertThat(entity, is(validEntity()); 

in a JUnit test, peachy.

But I can't do

assertThat(entity, not(validEntity());

because the validEntity fails with broken asserts, while for not I guess it should just return false.

Clearly I'm doing something backwards here but I'm not sure what's the most clever way of doing these custom matchers. Or maybe I shouldn't be using TypeSafeMatcher at all but doing something different?

Answer 1

Your matchesSafely method should be rewritten to avoid throwing assertion failures. Instead, just perform the checks manually and then return false if necessary.

Then, you can negate it in the manner you desire without consequence.

Answer 2

You should not be using assert methods in the matchesSafely. You should only be doing boolean logic to return either true or false. It is the responsibility of the calling code to throw the assert error and / or wrap in the not. Therefore you should be doing something like this:

public boolean matchesSafely(...){
       boolean result = true;
       result &= value1 == value2;
       result &= entity.getVal2() == someOtherVal2;
       return result;
}

Answer 3

While the other answers are more correct, another approach might be to catch your exceptions within the matcher and then return false while swallowing the exception and returning true otherwise.

This is not ideal.