"waitFor" in react-testing-library doesn't work with Jasmine about jasmine HOT 6 CLOSED

My thought is that we could add a an API for just the DSL and put it under a different function ("check" comes to mind but it doesn't feel quite right with the assertion names) and that would throw a plain JS exception instead of reporting back to jasmine.

I think any name other than "expect" is going to feel at least somewhat awkward. And I think that's partly a good thing: someone who thinks the proposed feature is a synonym for "expect" is more likely to stick with "expect" if code using the new feature reads worse. If anything, "check" isn't awkward enough. I'd favor something like "throwUnless", which might also give the reader a fighting chance at correctly guessing the implications of using it.

Since a user would need to explicitly opt-in to this behavior by using the alternative function, we would be able to make them aware of the behavioral difference between the 2 forms.

Well, we can try. Some people will actually read the docs before trying out a feature that they're unfamiliar with. But not everyone will.

from jasmine.

Rock and a hard place!

Indeed.

I'm not sure how to solve this in a way that doesn't create worse problems.

React-testing-library's design assumes that failed expectations throw exceptions, and don't count unless the exception propagates back to the testing framework. But that's not the way Jasmine works. (And Jasmine had already not worked that way for nine years when react-testing-library first came out.) If expectations work the way react-testing-library assumes, then this code can't work any more:

it('does something async', function(done) {
   doSomethingAsync(function(result) {
      expect(result).toBeCorrect();
      done();
   });
});

That sort of code (which is extremely common) relies on expectation failures "counting" even if they can't propagate an exception back up to the rest of Jasmine.

Making expectation behavior configurable has problems too. For one thing, waitsFor usage and code that makes the same assumptions as the example above can occur in the same suite or even in the same spec. So even if it's opt-in, it's still a footgun. Then there's the problem of explaining how async testing works when it works two different ways depending on how Jasmine is configured. And fielding "why don't my expectations work" issues from users who don't mention their Jasmine configuration because they don't realize it's relevant.

I'm not sure I want to take on the complexity of a second expectation-processing mode just for react-testing-library. My knee jerk reaction is that the juice probably isn't worth the squeeze. But even setting that aside, I think we'd need something that's opt-in at the call site, difficult to misuse, and designed in a way that makes its purpose and effects obvious. I'm not sure what that would look like.

from jasmine.

3.4.0 (sorry!) - I'm 99% sure this will happen on all versions though.

You're right that it'll happen on all versions. But even if Jasmine did ship something to better support react-testing-library, it wouldn't be backported to 3.x.

from jasmine.

Maybe something like this, which I think is in line with your suggestion of making it contextual?

await waitFor(() => { expect(input.getAttribute("value")).forTestingLibraryWaitsfor().toBe("gamma") } );

But I'm not sure it's all that much less obnoxious than what you're already doing. And it still wouldn't work if the waitFor call was in an async callback.

from jasmine.

It seems to me like the fundamental issue here is that there are two separate things being tied together in the "expect" API. The first is the DSL for assertions (which is useful even outside the context of jasmine) and, the second is the mechanism that reports the error back to jasmine to be gathered and displayed. In the RTL example, we'd really like to access just the DSL but, since the reporting comes along with it, we end up constrained by that extra functionality.

My thought is that we could add a an API for just the DSL and put it under a different function ("check" comes to mind but it doesn't feel quite right with the assertion names) and that would throw a plain JS exception instead of reporting back to jasmine.

I think this would solve for the RTL use case and, it would manage to avoid the confusion arising from overloading the expect API. Since a user would need to explicitly opt-in to this behavior by using the alternative function, we would be able to make them aware of the behavioral difference between the 2 forms.

from jasmine.

throwUnless (or something like it) would also be reasonable for a linter to pick up too, which is appealing.

from jasmine.