Async tests about jest HOT 24 CLOSED

waitsFor is not a thing in jasmine 2 so how do you it there?

from jest.

Just so you know, jasmine-pid doesn't seem to work with Jasmine 2 at all.

The solution is to use jest.useRealTimers() and jasmine's own async support.

   it("takes a long time", function(done) {
      // do something
      setTimeout(function() {
        // run your expectation
        done();
      }, 1000);
    });

from jest.

You can use the standard jasmine runs() and waitsFor() calls or you can use pit instead of it and return a promise from your test function.

from jest.

See jasmine-pit docs for more info on that, btw.

from jest.

#74 is relevant. 👍 to this/that

from jest.

Can this be reopened. There is still no way to test functions with async callbacks.

In my case, I want to write an integration test with supertest. As supertest doesn’t return a promise I can’t use pit.

from jest.

@spicyj If you can show me the most basic example with runs and waitsFor that actually work on a real $.ajax call I will sign my house over to you.

I get time out 100001% of the times.

from jest.

@gbbr Are you trying to mock $.ajax or have it actually perform the network request?

from jest.

The actual network requests (for integration testing), although I've eventually figured it out, which is good because I'd live to keep my house :)

from jest.

Hey @gbbr , what is your solution? I'm getting time outs as well all the time.
For some reason the setTimeout I put in the first run function is never executed?

from jest.

👍 Having the same problem with timeouts no matter how long they're set.

from jest.

Please read JEST documentation more carefully. setTimeout is always
mocked

On 14 April 2015 at 06:09, Matt Norris [email protected] wrote:

[image: 👍] Having the same problem with timeouts no matter how long
they're set.

—
Reply to this email directly or view it on GitHub
#42 (comment).

from jest.

@gbbr That's correct.

But what can we do if we want to use setTimeout in our jest tests, like waiting a certain amount of ms for an event to be handled?

e.g.

it 'edit routes', (done)->
  riot.route 'todos/edit/1'
  setTimeout ->
    calls = todo_presenter.edit.mock.calls
    expect(calls.length).toBe 1
    paras = calls[0][0]
    expect(paras).toBe '1'
    done()
  , 1000

Any suggestion for work around?

from jest.

Technically you should never have to use setTimeout in tests. Ever. If you
want to wait for anything just use "runs" and "waitsFor".

On Friday, April 17, 2015, Andrew Feng [email protected] wrote:

@gbbr https://github.com/gbbr That's correct.

But what can we do if we want to use setTimeout in our jest tests, like
waiting a certain amount of ms for an event to be handled?

e.g.

it 'edit routes', (done)->
riot.route 'todos/edit/1'
setTimeout ->
calls = todo_presenter.edit.mock.calls
expect(calls.length).toBe 1
paras = calls[0][0]
expect(paras).toBe '1'
done()
, 1000

Any suggestion for work around?

—
Reply to this email directly or view it on GitHub
#42 (comment).

from jest.

waitsFor won't work for this case because I just want to wait a certain amount of time elapsed before execute the function, as normal setTimeout does; waitsFor will wait that amount of time maximally for the execution of the function, so it actually executes it immediately.

setTimeout is more like sleep, waitsFor is not.

from jest.

Like this? (sorry I don't know CoffeeScript, but hopefully you get the idea)

it("edit routes", function() {
    runs(function() {
        riot.route("todos/edit/1");
    });

    waitsFor(function() {
        return todo_presenter.edit.mock.calls === 1;
    }, "presenter to be called", 1000);

    runs(function() {
        expect(todo_presenter.edit.mock.calls[0][0]).toBe(1)
    });
});

The above should do exactly as your example, without setTimeout. Again, you should never use setTimeout in tests, it's a bad practice. The above script does the same, and potentially saves your test runner a lot of time.

from jest.

It works, great!

BTW, not sure why setTimeout is considered bad in tests. For me it looks normal if I want to assert event handler to be called, in which the event is dispatched asynchronously.

from jest.

Andrew, imagine the following scenario:

• Your test has a timeout that waits 5 seconds before checking that a
  callback is complete
• The callback completes after 500ms
• The test will be IDLE for 4.5 seconds more which is a complete waste of
  time.

Now, put the above scenario in a test suite with 300 tests and imagine how
long it would take for that suite to run. Or what if you are running your
tests as you write code? It can quickly get frustrating to wait extra
unneeded time for this. Feel free to Google this too if you need more
information.

On 20 April 2015 at 07:43, Andrew Feng [email protected] wrote:

It works, great!

BTW, not sure why setTimeout is considered bad in tests. For me it looks
normal if I want to assert event handler to be called, in which the event
is dispatched asynchronously.

—
Reply to this email directly or view it on GitHub
#42 (comment).

from jest.

It's kind of an edge-case but I'm working to fix a problem which comes from updating input components asynchronously. First thing I wanted to do is write some async tests, but there is no facility in react for this. Any chance that this will still be considered, it can be useful for edge cases.

from jest.

See http://jasmine.github.io/2.0/introduction.html#section-Asynchronous_Support

jasmine 2, pit and runAllTimers should provide enough options for async testing.

from jest.

We have extensive documentation on how to work with async/await and Promises: http://facebook.github.io/jest/docs/tutorial-async.html#content

from jest.

@cpojer the above link is broken

from jest.

http://facebook.github.io/jest/docs/en/tutorial-async.html#content

from jest.

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Please note this issue tracker is not a help forum. We recommend using StackOverflow or our discord channel for questions.

from jest.