✅ Use jasmine for testing

[wwilsman]

What is this?

In preparation to add browser support for @percy/logger and @percy/sdk-utils, their test suites (along with @percy/dom) were evaluated.

While Mocha is supported in browsers, Jest's expect is not. This is handled in @percy/dom by not including Jest's expect and instead using a thin helper mimicking the expect API. This helper from @percy/dom would need to be included in browser tests for @percy/logger and @percy/sdk-utils, however these two packages still need to be tested in Node since they will be polymorphic.

We could have two test suites for these packages — one for Node and one for browsers; or we could perform browser-only test aliasing to ensure Node specific code is replaced with browser compatible code. Instead, this PR proposes migrating to Jasmine, which includes its own expect with a very similar API; as well as Jasmine is specifically built to be polymorphic. It also contains its own spy library which we can utilize rather than the current manual mocks and spies.

Approach

Migrating the tests themselves was pretty straightforward since Mocha's and expect's APIs are very similar to, or in most instances exactly the same as, Jasmine's APIs. For the APIs that did not perfectly match, a codemod was used to transform all of the tests using the same set of rules (which also makes it super easy to list below).

One Jest expectation does not exist in Jasmine but is used everywhere, toHaveProperty(key, value). The Jasmine equivalent is a bit more verbose, toEqual(jasmine.objectContaining({ key: value })), and doesn't work with nested key paths. Rather than make this into a transform, a global test-helper util is used to add a custom toHaveProperty Jasmine matcher. This global test-helper also overrides another Jasmine matcher, toContain, to add support for deeply checking Sets. The Jasmine variant wants to support IE, which cannot perform a deep check on Sets without the performance tradeoff of transforming the Set into an array.

Finally, manually added mocks, stubs, and spies were replaced with Jasmine's spyOn, as well as associated expectations updated to use Jasmine's Spy expect matchers.

Code Transforms

Test hooks:

- before()
+ beforeAll()
- after()
+ afterAll()

Async expectations:

- expect().resolves.toBe()
- expect().resolves.toEqual()
+ expectAsync().toBeResolvedTo()
- expect().resolves.toBeDefined()
- expect().resolves.toBeUndefined()
+ expectAsync().toBeResolved()
- expect().rejects.toThrow()
+ expectAsync().toBeRejectedWithError()

Expectations with different method names:

- expect().toContainEqual()
+ expect().toContain()
- expect().toHaveLength()
+ expect().toHaveSize()
- expect().toThrow()
+ expect().toThrowError()

Static expect helpers:

- expect.<fn>()
+ jasmine.<fn>()
- expect.stringContaining()
+ jasmine.stringMatching()

Other Changes

A custom test script is used in order to add the jasmine-spec-reporter which can only be added programmatically (and not via the CLI). Some Jasmine options are also not available as CLI options, so the test script makes it easier for all monorepo packages to share the same test setup.

The tests seem faster? Which revealed a @percy/core test failure in which a method called during a page crash did not handle asynchronous errors, causing an unhandle promise rejection warning. Coverage of the failure is flakey and ultimately only needs to be handled to prevent the promise warning so is ignored. Other @percy/core tests needed to escape path separators for Windows since Jasmine's stringMatching helper handles substrings differently than Jest's.

[Robdel12]

🏁 We've been sleepin on Jasmine