[testing] chai plugins

Using chai plugins with @open-wc/testing is tedious and undocumented.

root cause & context

Chai and most chai plugins aren’t exposed as es modules.

This led to the creation of @bundled-es-modules/chai and the following issues:

• https://github.com/domenic/sinon-chai/issues/138
• https://github.com/nathanboktae/chai-dom/issues/38
• other issues I don’t know about go here 😉

Thankfully, there still is some Chai Plugins which support ESM:

• https://github.com/astorije/chai-immutable
• https://github.com/hellosmithy/chai-rx
• https://github.com/bustle/chai-graphql

But these projects don’t seem to be actively maintained anymore. So, there isn’t any advancement on this right now.

current options

Developers using @open-wc/testing do not have many good options when using chai plugins.

A. esm fork

👉 https://github.com/nathanboktae/chai-dom/issues/38#issuecomment-519068027

B. define plugins globally

Most chai plugins (chai-dom, sinon-chai, chai-datetime) fall back to using window.chai.use when AMD, CommonJS, etc… aren’t available:

Some others, like chai-http, only provide a “global import” syntax. We can use those the same way as showen bellow, by using a static import statement and then calling chai.use.

So, we can:

1. install the “official” (non esm) packages npm i -D chai-dom sinon-chai

2. import chai from bundled-esm-modules/chai, add it to window.chai, and then dynamically import the plugins packages:

https://github.com/noelmace/devcards/blob/cf0fe84deb338c47699b2aa289100b9834a68e84/test/utils/chai-plugins.js#L1-L6

FYI, window.chai doesn’t exist in the imported package if you use static import statements instead, but I don’t see any workaround for that.

1. add this file to karma files:

https://github.com/noelmace/devcards/blob/cf0fe84deb338c47699b2aa289100b9834a68e84/karma.owc.conf.js#L8-L9

proposals for resolution

1. I feel like option B is the best workaround right now. We could add it to the doc. What do you think?
2. Regarding option A, as most Chai plugins aren’t maintained anymore, and owners don’t answer issues, @open-wc / @dakmor & folks, could provide some esm-modules forks (at least for chai-dom and sinon-chai) and actively maintain those.

BTW, I’m personally concerned about Chai and its plugins maintenance. Even if they are way more popular right now, this is why I tend to favor jasmine for WC testing. Could you explain why Mocha/Chai was chosen for open-wc/testing in the first place?

[daKmoR]

Using karma-jasmine, I get exactly the same file in the browser, except the link to the source-map is added at the end. But with Mocha, I get:

the transformation you see is for code coverage… it has “nothing” to with mocha… I assume you would get the same transformations if you apply code coverage and you run it with jasmine

Jasmine requires the describe/it syntax, which is pretty bad, IMO

hehe I see this as another “holy” war - equal to tabs vs spaces or " vs '… let’s not open this particular pandora’s box here 🙈

In the Polymer projects we use mainline Mocha and Chai, and just load any other needed files via script tags.

something to test out 💪

we will probably need to change our existing plugins or at least load them differently as I assume that is why @noelmace sees the errors when not using the bundles es module version of chai…

[daKmoR]

the status of chai plugins is the same as for many other libraries when it comes to es modules… adoption is slow as node is the primary target for many… and node by default still does not support es modules 😭

if there is a simple way to use the “normal” chai and not a bundled-es-modules version then we should totally do and recommend that… 🤗 if we can’t do it for chai but somehow we can do it for plugins - that also would be a win 👍

so if you could do a PR for option B that would be awesome 💪

Just to be sure our primary goal is still to test code natively in the browser (e.g. no transformations* or adjustments to the code before it gets shipped to the browser)**.

Could you explain why Mocha/Chai was chosen for open-wc/testing in the first place?

According to our defined goal of using native es modules without any transformations in the browser mocha/chai was our best bet (back then I knew at least how to make es modules work in mocha; while I did not know it for jasmine) how is support for es modules in jasmine nowadays?

* with the exception of bare module ** when testing on older browsers transformations are applied