The mocking of timings provided natively by Jest is fantastic, by calling jest.useFakeTimers the timeout functions become mocks and you can advance "time" by a fake number of milliseconds or run all pending timers or all timers to check that behavior works as expected. Of course, there are hidden gotchas, as you'll want to reset all mocks after each test runs but mostly it is easier than custom rolled timeout handling. Not to take away from your work - what you designed is basically what jest provides internally
There’s a similar “time” pattern in Jasmine, I believe. The issue here was a client with an existing code-base, including thousands of tests already in Jasmine. In fact, they prefer to only upgrade 3rd party code when it’s clearly broken ... which explains the odd pattern we worked out in this article.
Thanks again for the information. I may jump in and experiment with Jest one of these days!
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The mocking of timings provided natively by Jest is fantastic, by calling
jest.useFakeTimersthe timeout functions become mocks and you can advance "time" by a fake number of milliseconds or run all pending timers or all timers to check that behavior works as expected. Of course, there are hidden gotchas, as you'll want to reset all mocks after each test runs but mostly it is easier than custom rolled timeout handling. Not to take away from your work - what you designed is basically what jest provides internallyAwesome! Good to know.
There’s a similar “time” pattern in Jasmine, I believe. The issue here was a client with an existing code-base, including thousands of tests already in Jasmine. In fact, they prefer to only upgrade 3rd party code when it’s clearly broken ... which explains the odd pattern we worked out in this article.
Thanks again for the information. I may jump in and experiment with Jest one of these days!