Add tests for utils

[jimbo]

No description provided.

[DrewML]

Can we drop the describe so we're matching our tests across our other repos?

test('extract retrieves a named export');
test('extract retrieves the default export');

[jimbo]

Sure. I think when this file has a few more functions the test output will be unreadable if not grouped by describe, but then, they're just tests.

[DrewML]

If we're listing the params, would make sense to list the return (then VSCode/Webstorm will give proper hinting).

@returns {Promise<*>}

[DrewML]

Not a fan of having 2 separate Babel configuration files. We should choose 1 and confine all babel-related config to it

[DrewML]

If you want to keep the JS version, jestjs/jest#1468 (comment)

[jimbo]

Yeah, I'm also not a fan of it. I considered moving everything to .babelrc, but it's pretty verbose that way. Could still be better than hacking jest, though.

[DrewML]

Whatever route you choose is just temporary until Babel 7, and then we have first-class support for .babelrc.js

[zetlen]

Let's keep 2 files instead of using a hack. More maintenance, but the maintenance burden is obvious.

[jimbo]

That's my instinct here as well, @zetlen. And @DrewML we should consolidate both files into .babelrc.js as soon as we're on 7.0 then.

[DrewML]

Any particular reason you're using an assertion counter? Typically only needed for async code where the "bad" path would exit without throwing.

Example:

test('Should throw', async () => {
   try {
      await foo();
      // if foo does not reject, test passes (incorrectly)
   } catch(err) {
       expect(err).toBeTruthy();
   }
});

[jimbo]

Nope, no reason. Saw it in other tests @zetlen wrote and imitated it without opinion.

[DrewML]

It's not a huge deal here (small tests), but I have a strong pref in general to not use it when it isn't necessary. Last employer started having 50+ line tests, and any test you edited always failed because you'd forget to change the assertion counter - became a PITA.

[zetlen]

Yeah, I only add it when during my development of the test, it somehow passed without running my async assertions. I probably shouldn't do it--I should add expect.hasAssertions() for asserting any amount of later async assertions, which needs less upkeep.

[zetlen]

Looks good, nothing here is blocking--just comments!

[zetlen]

Let's keep 2 files instead of using a hack. More maintenance, but the maintenance burden is obvious.

[zetlen]

Testing rejections has been really annoying in Jest, but since this was fixed in 22, you can write a nicer test here:

test('throws if the module fails to resolve', () =>
    expect(extract(null)).rejects.toEqual(error)
);

(You don't have to async/await if you can return the Promise directly out of the test.)

[jimbo]

Sure, I can remove the superfluous await.