Add example for React + Enzyme

[dylans]

Investigate https://github.com/airbnb/enzyme and consider adding an example.

[crazyscience]

Any progress on this @dylans?

[dylans]

@crazyscience not yet, it's on my list to look at, just hasn't made it to the top yet. If you're interested in it and wanted to help out, that would be great (if not, no worries).

[brettdewoody]

+1 - I'm happy to pair with others if anyone wants to focus on a working example/setup. After a day+ of attempts I switched to Mocha/Enzyme and had unit tests running in 30 minutes. Love the idea of using Intern for both unit/functional so it'd be great to get it working.

[dylans]

ok, happy to collaborate @brettdewoody ... I have zero time this week, but maybe next week?

[brettdewoody]

Great, let me know when you have some time.

[dylans]

Ok, I've had some time to think about this. I think the main thing actually needed for the example is to either offer a loader plugin to transpile Enzyme to ESM, or the example needs to be authored as ES6/ESM, with it being clear how to transpile it before testing and then hooking into remap-istanbul to preserve code coverage.

[brettdewoody]

Agreed. In our case we're dealing with the latter. My gut is this is the more common case as many React examples are authored in ES6/ESM.

[dylans]

We agree that ESM is a good syntax, but there are some challenges.

• ESM doesn't provide a convenient way for many of the dynamic loading features we provide via AMD loader plugins, which either adds a lot of boilerplate to the authoring of tests, or forces us to write a secondary loader for things that ESM loading doesn't handle. TypeScript and SystemJS both support plugins, e.g. import * as registerSuite from 'intern!object';, but that's not part of the standard. It's a feature we commonly use for only loading a test if you're running in a particular environment (e.g. run these tests when in Node, these tests when in a browser)
• Map configuration, supported via AMD and SystemJS, but not part of the ESM standard, which makes it easy to map dependencies for mocking
• Module imports must be at the top of a file (no logic allowed to check the environment to then determine what to import
• To mechanism to unregister and re-register a module (also commonly used for mocking)

So really the challenge we face in moving from AMD to ESM for Intern is that we have some difficult work ahead to provide the features we currently offer. It's possible (and in fact easier with TypeScript than ES6).

Anyway, back to the problem at hand. :)

[dylans]

Note that we're pretty close with Intern 4 and its support for ESM, which will make this easier, so my plan is to complete this to coincide with Intern 4 when it's ready sometime this year.

[brettdewoody]

Great, thanks for the update.

[draperd]

@dylans I'm really interested in the ESM support you've mentioned and I'm pleased to hear you say that Intern 4 is very close. In our case we need ESM support to be able to import the CSS classnames that are exported by each React component that we want to test. Do you have any more information on when Intern 4 will be ready - the current milestone says June 30th, but nothing is marked as complete yet! ... is that a realistic date to work to? and would you expect to be able to mix and match ESM imports with the current style of authoring functional tests in AMD (i.e. having an import statement at the top of the test say?)

[dylans]

@draperd that's still our goal, though of course it depends on things going smoothly. One of the main changes with ESM over AMD is the lack of loader plugins, so we are generally moving away from AMD as the test authoring format, though you could still author tests with AMD if you prefer. I would not suggest a mix and match of ESM and AMD in the same file as I think that would lead to significant confusion.

[draperd]

@dylans OK... that's fine, at the moment we're just getting started on a new project so I'm happy to wait for ESM support (and if we write any tests now with duplicated variables we'll port them back over later).

Thanks for the update on this. I'm really looking forward to this next release. I've been using Intern with great success for the last few years and although I took a look around at some other options that are now available I've decided to stick with Intern because it does what we need so well. The update to ESM support should hopefully also help with further adoption for those who aren't familiar with or prepared to learn AMD.