babel/generator-babel-boilerplate

Determine ideal testing setup

Closed this issue · 4 comments

jamesplease commented

I want to support three different types of testing setups:

  1. Testing libraries only meant to be run in Node
  2. Testing libraries only meant to be run in the Browser
  3. Testing libraries that can run in both the Node and the Browser

This is pretty much already supported by the boilerplate, but I want to do two things differently with v6:

  1. tweak the environments for each use case using Yeoman prompts or flags
  2. allow for module stubbing

Right now, Webpack provides me with module stubbing in the browser, but it explodes on the server because obv. I'm not building for the server-side tests.

Related: #152

Some ideas:

  1. Build the app with webpack, even when running in Node. My opinion: kinda weird
  2. Only use Karma when the app needs to be built in the browser. This doesn't help with scripts that should work in Node, too. You'll want to just run those normally through Node. Opinion: too limited
  3. Browserify. I could use proxyquireify for the browser, and proxyquire in Node. Opinion: This might be the best option...maybe?
jamesplease commented

proxyquire-universal is a tool that allows one to author in both Node and the browser. I just need to check if it interops with Babel.

The worst-case scenario is that I'll need to use Babel to compile to CJS in a separate step before running it as a Node script. Would this be any better/worse than compiling it with Webpack before running it in Node? Not sure.

Another idea to support each use case separately would be a prompt that is:

Where do you intend for this library to be run?
  - Node
  - Browser
  - Both
jamesplease commented

Another thing to consider is that this needs to work with Istanbul for code coverage reports.

So the hardest thing to find will be the libs that need to run in Node and the browser.

  1. Node.js stubbing (running npm run test). Will ideally just use a Mocha gulp task.
  2. Browser stubbing. Might run it through Webpack/Browserify, and then either Karma or a spec runner
  3. Istanbul for code coverage

Browserify just might be the answer:

  1. Proxyquire for Node (using the universal plugin)
  2. Proxyquireify for browser (using the universal plugin)
  3. browserify-istanbul for code coverage (along with the universal proxyquire plugin)

This relies on the istanbul transform interoping with the proxyquire and babel transforms, which may or may not work. Also, some of the issues on the istanbul tool seem pretty limiting. I might need to fix those up.

jamesplease commented

Closing as this is fixed by babel-plugin-rewire. Although there won't be any changes to this boilerplate for this, I'll be setting up an example in the testing-with-babel repo that can be used as inspiration. I may add a note to the README here to reference that repo, but...that's a separate issue.