Support use of Swal in Jest testing environment

New feature motivation

A few days ago I was working on https://github.com/sweetalert2/sweetalert2-react-content/pull/72, and when I left it, the last commit (https://github.com/sweetalert2/sweetalert2-react-content/pull/72/commits/33fe8d658e48c466325e77dde8b33488519c8cfc) had passing tests.

When I came back to it a couple days later, the same commit had failing tests due to the v8.2.3 patch release.

I managed to reproduce the bug in the swal-not-resolve-in-jest-bug repo. You can see that the build for the master branch (using sweetalert v8.2.2) is passing, but the build for the upgrade-sweetalert2-to-v8.2.3 branch is failing, due to the swal instance never resolving. (No idea why to be honest… at first glance, the changes from v8.2.2 to v8.2.3 don’t seem like they would cause this kind of problem)

Jest is an incredible testing tool, and it would be nice if sweetalert2 was supported [consistently] in this environment.

New feature

I propose to add first-class support for Jest, by doing the following things:

1. Add check:jest to the package scripts, with only one or two very basic tests, as “smoke testing” for the Jest environment. Fine-grained testing of functionality should continue to happen only in the existing karma+qunit test environment.
2. Debug and fix the above mentioned problem (reproduced in https://github.com/sweetalert2/swal-not-resolve-in-jest-bug).
3. Not strictly needed, but would make testing in Jest nicer: Check for existence of window.scrollTo before calling it, to avoid the need to mock it here: https://github.com/sweetalert2/swal-not-resolve-in-jest-bug/blob/f06bbd41dc51716810cd274e5e4efa7e581d5383/test.js#L4-L7

[limonte]

🎉 This issue has been resolved in version 8.3.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀

[SimenB]

The code coverage dropped to 62%

While the code coverage certainly should be higher, it’s also a bit misleading here. Jest has ~500 separate integration tests which spawns up an instance of Jest on different tests and scenarios and performs asserts on its output. This is not something that’s reflected in the code coverage numbers, as those are just from unit tests. So, while I agree ~60% is lower than it could (and should) be, the code base is better covered by tests than that number indicates.

https://github.com/facebook/jest/tree/master/e2e/__tests__

the Travis CI dashboard is still as red as the Chinese communist parade.

Note that Jest does not run tests from master in Travis (see your screenshot, the last build is 4 months ago), since travis thinks we inject some secret, turns off tty, which means all colors are borked (https://github.com/travis-ci/travis-ci/issues/7967#issuecomment-358437261). We run on PRs though to verify Jest itself works on Travis, since they are from forks they are not privileged. We run tests for node 6, 8, 10 and 11 on Linux on circleci, node 10 for windows, mac and linux on Azure pipelines and node 10 on appveyor for windows (we’ll remove that last one at some point since it’s covered by azure). All of which are green (or in progress at the time of writing)

https://circleci.com/gh/facebook/jest/tree/master https://dev.azure.com/jestjs/jest/_build?definitionId=1 (I’m not sure how to filter to just master there)