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

ToBeType matcher always return true #34

Closed
allphat opened this issue Jul 18, 2013 · 12 comments
Closed

ToBeType matcher always return true #34

allphat opened this issue Jul 18, 2013 · 12 comments

Comments

@allphat
Copy link

allphat commented Jul 18, 2013

Example : testing a simple json like {title: 'my string'}

.expectJSON({title: function(val) { expect(val).toBeType(String); }}) => test pass
.expectJSON({title: function(val) { expect(val).toBeType(Number); }}) => test pass
.expectJSON({title: function(val) { expect(val).toBeType(Array); }}) => test pass

I

@allphat
Copy link
Author

allphat commented Jul 18, 2013

for a quick check, I've cloned this repo in a new folder.

If I run frisby_mock_request_spec.js, all tests pass.
Now, I edit this file changing :
"id": function(r) { expect(r).toBeType(Number); }, to "id": function(r) { expect(r).toBeType(String); },

I rerun this test ans it still passes

@vlucas
Copy link
Owner

vlucas commented Jul 18, 2013

I will take a look at this. This definitely should not be happening.

@vlucas
Copy link
Owner

vlucas commented Jul 23, 2013

Okay. I looked into this, and it's a bit weirder than the matcher not working. The matcher actually works perfectly. If you return from the function the result of the expect call, the test will fail.

Example:
"id": function(r) { return expect(r).toBeType(String); }

So the issue is that the Jasmine expectation is failing, but Frisby is somehow ignoring it if not returned directly. Running a few tests, it also does not add to the assertion count. It's almost like it's being run in a separate context or something. I will continue to investigate this issue, but I just wanted to give you a heads up in the meantime.

@allphat
Copy link
Author

allphat commented Jul 25, 2013

Thx for the update :)

@TheRaven
Copy link

I have a similar problem, but in afterJSON

@jturmel
Copy link
Contributor

jturmel commented Oct 30, 2013

Any word on this? It also seems to affect toBeTypeOrNull -- doesn't matter what you set it to Number, String, whatever...

@katerberg
Copy link

This still appears to be an issue.

@jjair81
Copy link

jjair81 commented Nov 6, 2014

Seems like this is still the case for me too. I have some a json response as so:

{
"responseItems": 1,
"response": [ {
"element1": "some text",
"element2": "some text",
"element3": "some text",
} ]
}

doing a expect(val).toBeTypeOrNull(number/string/array/object) all work.

@andrecastelo
Copy link

Still happening, returning the expect function. Also happens with toBeTypeOrNull.

@sharadJay
Copy link

any updates on this ?

@vlucas
Copy link
Owner

vlucas commented Mar 17, 2016

I am working on the next version of Frisby, which will fix this issue. The main issue here is that Jasmine will not reliably run assertions in nested contexts.

@vlucas
Copy link
Owner

vlucas commented Jul 26, 2017

Fixed in v2. Please update.

@vlucas vlucas closed this as completed Jul 26, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants