ToBeType matcher always return true about frisby

[allphat]

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]

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

[vlucas]

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]

Thx for the update :)

[TheRaven]

I have a similar problem, but in afterJSON

[jturmel]

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

[katerberg]

This still appears to be an issue.

[jjair81]

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]

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

[sharadJay]

any updates on this ?

[vlucas]

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]

Fixed in v2. Please update.