Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The signature of isA is completely wrong #27

Closed
time4tea opened this issue Jan 29, 2013 · 20 comments
Closed

The signature of isA is completely wrong #27

time4tea opened this issue Jan 29, 2013 · 20 comments
Milestone

Comments

@time4tea
Copy link

public static org.hamcrest.Matcher isA(java.lang.Class type) {
return org.hamcrest.core.Is.isA(type);
}

means you have to cast the thing to the type you are asserting it should be. Really it should be a matcher of anything (Object) not T.

e.g.
class hierarchy Foo extends Bar

Bar thing = somemethod();
assertThat(thing, isA(Foo.class))

to assert that you are getting the right subclass back - yeah ok, it might not be the best test, but anyhow......

@time4tea
Copy link
Author

"completely wrong" were Nat's exact words btw - nothing to do with me.... :-)

@scarytom
Copy link
Member

This is interesting in conjunction with some of Nat's other discussions on the matter:
http://code.google.com/p/hamcrest/issues/detail?id=83#c13

@npryce
Copy link
Contributor

npryce commented Jan 29, 2013

It should be <T> Matcher<Object> isA(Class<T> expectedType, Matcher<? super T> downcastMatcher)

@time4tea
Copy link
Author

Which is a matcher of object not T. That would do it I think.
On 29 Jan 2013 22:11, "Nat Pryce" notifications@github.com wrote:

It should be Matcher isA(Class expectedType, Matcher<? super T>
downcastMatcher)


Reply to this email directly or view it on GitHubhttps://github.com//issues/27#issuecomment-12861355.

@scarytom
Copy link
Member

I'll have a go at this soon... watch this space :)

@time4tea
Copy link
Author

oddly all the angle brackets in the type signature didn't appear in the email i got from github... hence my comment about Object, not T - which you can see here but not in the email...

@durron597
Copy link

I'm surprised this hasn't gotten more attention! This is a problem in the most obvious use case, i.e.

import static org.hamcrest.core.IsInstanceOf.*;
import static org.hamcrest.core.Is.*;

import org.junit.Test;

import static org.junit.Assert.*;

public class HamcrestTest {
    interface FooInterface { }
    class Foo implements FooInterface { }
    class FooBar extends Foo { }

    @Test
    public void isTest() {
        Foo someFoo = new FooBar();
        FooInterface interfaceRef = someFoo;
        assertThat(someFoo, isA(FooBar.class)); // Doesn't compile
        assertThat(interfaceRef, isA(Foo.class)); // Doesn't compile

        assertThat(someFoo, instanceOf(FooBar.class)); // Compiles correctly
        assertThat(interfaceRef, instanceOf(Foo.class)); // Compiles correctly
    }
}

@EarthCitizen
Copy link

Has there ever been any progress on this issue? I made my own version of isA() to get around the issues discussed here.

@scheffield
Copy link

@EarthCitizen: would be nice to see it as a Gist.

@EarthCitizen
Copy link

isA() is an alias for instanceOf() is it not? What about something like isClass() for exact Class matching?

@npryce npryce added this to the 2.1.0.0 milestone Jan 5, 2015
@npryce npryce modified the milestones: 2.1.1.0, 2.1.0.0 Jan 5, 2015
bitzl added a commit to bitzl/JavaHamcrest that referenced this issue Nov 28, 2015
The method isA needs to create a Matcher for arbitrary objects to support matching of superclasses as is(instanceOf(...)) does to make both calls equivalent.
@bitzl
Copy link

bitzl commented Nov 28, 2015

I've submitted an Pull Request (#127) to fix this. The behavior of isA is documented as shortcut to instanceOf. I've enhanced tests to check if the beavior is similar and changed the methods return a Matcher<?> instead of Matcher<TheClass.class>.

@sf105
Copy link
Member

sf105 commented Apr 7, 2016

Fixed

@sf105 sf105 closed this as completed Apr 7, 2016
@massenz
Copy link

massenz commented Jul 11, 2016

Could you please give us an indication of which version this was/will be released for?
I'm currently using java-hamcrest:2.0.0.0 and it still has the same incorrect signature.

Thanks.

@durron597
Copy link

This change hasn't been released yet. I'm not a Hamcrest member so I can't tell when they plan to release the next one, but for now it looks like you'll have to build from source.

Unfortunately master still has the version number listed as 2.0.0.0, so you'd probably have to change that in your build if you're going to add it to a local repo.

@udalrich
Copy link

Any hope of this eventually being released?

@durron597
Copy link

I think the problem is that the version in CoreMatchers never got fixed

@micheal-hill
Copy link

hamcrest:2.1 has this problem...

@ProYI
Copy link

ProYI commented Jun 28, 2020

junit:4.13 depend on hamcrest-core:1.3 also has this problem

@nhojpatrick
Copy link
Member

hamcrest:2.1 has this problem...

does org:hamcrest:hamcrest:2.2 have the problem?

@nhojpatrick
Copy link
Member

junit:4.13 depend on hamcrest-core:1.3 also has this problem

feel free to raise PR with junit so v4.14 could be upgrade to the latest version, that being currently org:hamcrest:hamcrest:2.2

v1.x is dead and out of support
v2.x i'm still trying to learn the guts and help with patches... so semi in support

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.