Support use of Swal in Jest testing environment

[zenflow]

New feature motivation

A few days ago I was working on sweetalert2/sweetalert2-react-content#72, and when I left it, the last commit (sweetalert2/sweetalert2-react-content@33fe8d6) 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

[zenflow]

Note: This is an issue with Jest v23 and Jest v24

[limonte]

I managed to reproduce the bug in the swal-not-resolve-in-jest-bug repo.

This issue is weird, thank you for making the repo @zenflow!

While on the upgrade-sweetalert2-to-v8.2.3 branch, make this change in node_modules/sweetalert2/dist/sweetalert2.all.js:

-  return !!(elem && (elem.offsetWidth || elem.offsetHeight || elem.getClientRects().length));
+  return true

Tests are passing.

Also, they are passing with

  return elem

But they are failing with

  return elem.offsetWidth

---

Jest is an incredible testing tool

I wonder how something can be incredible if it's failing without any sane reasons and without any helping information on why and where did error occur?

The hype around jest is incredible indeed, but its quality is questionable.

64% code coverage and the screenshot below don't really correlate with "incredible" to me:

Looks like a joke, testing framework with constantly failing master...

---

This issue is most probably on jest's side and the proper place to report it is https://github.com/facebook/jest/issues along with hundreds of other issues.

Add check:jest

I think one testing framework is enough. If someone has time and will to debug jest, please do so, but I'm against adding the complexity of dev environment to this repo because of jest's bugs.

3. Check for existence of window.scrollTo before calling it, to avoid the need to mock it here

Same here, adding code complexity and increasing the bundle size because some things are missing in some testing framework doesn't sound like a good idea to me.

[limonte]

Just checked the situating with jest once again. They finished jestjs/jest#7807 and released https://github.com/facebook/jest/releases/tag/v24.2.0-alpha.0

The new jest release didn't fix the issue with SweetAlert2 >= 8.2.3

The code coverage dropped to 62%, the Travis CI dashboard is still as red as the Chinese communist parade.

They seem to chase new technologies like TS instead of time-tested values as code coverage and the reliability of CI. Let's see if that will work well for them.

[limonte]

Reported the issue to jestjs/jest#8062

[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 (travis-ci/travis-ci#7967 (comment)). 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)

[limonte]

Thank you @SimenB I appreciate your time and the thorough explanation of why I was wrong with my doubts.

The CI status and code coverage are the very first things I'm personally checking before even considering to use any package because there are a lot of abandoned/unmaintained/untested projects. Using an unmaintained project is like pointing a loaded gun to your own knee, it will shoot sooner or later.

Travis is the default CI platform for OSS so that's why I checked it instead of other CIs. I'm still not following why it's not possible to set up Travis tests on master, but that's alright. Now I see that you are testing jest in other CI platforms in multiple environments and that's great! We're using Travis + AppVeyor as well for testing SweetAlert2 in multiple platforms.

If Travis isn't what you want to demonstrate, it might make sense to remove the Travis badge from the jest's README.

Thank you once again for putting your time on this ticket, it always feels great to get support from a core collaborator of a product. Keep up the great work on OSS!

[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 📦🚀