I'd like to offer an approach to make webpack-built projects easily testable. Right now I'm using the webpack alias babel plugin, but any special loaders are ignored, and that code cannot be tested without extracting it elsewhere.
Ava can watch globs, transpile, augment and run tests. Webpack can watch entries, use loaders, and run plugins.
To map one to the other, this would work I think:
ava-loader to do the power-assert stuff and anything else necessary, perhaps after the regular babel-loader ran.ava-plugin (much like start-server-webpack-plugin) to run Ava on all the entriesSo, the transpile/augment code would need to run in ava-loader and the run code would need to run in ava-plugin.
Does this seem like a correct approach? Is the code in such a state that ava-loader and ava-plugin would just run internal Ava API calls?
I don't know of a project that allows you to run a script in a child from a webpack in-memory fs, but transpiling to a temp dir is certainly acceptable for me.
Is the goal to test in the browser, or in Node?
Take a look at karma-ava for how it was solved with browserify. I looked at webpack as an option when developing that, but I don't remember why I didn't pursue it further. Specifically, check out lib/process-adapter.js, which polyfills anything Node specific.
Oops somehow I missed this. Yes, the goal is testing in Node. I also use webpack to run my server, and thanks to that I can do hot module reloading of my API code, great for development.
I have been thinking some more about this, and there is an easier first option, which already works:
target: "node" on one entry per test file (glob them in a function you give to entryAll loaders, aliases etc work as they should. As long as you don't add test files, this works. (webpack doesn't let you add entries on the fly AFAIK)
So the concept is working, but it would be a lot nicer if this could be done in a single process; apart from the convenience, hot module reloading could then probably be used to re-run tests faster? (although that would mean keeping each test process running, possibly not a good idea)
EDIT: Possibly the globbing process could assign multiple tests to concurrencyNum entries, and then the processes could stay active, only running tests whose modules are hot reloaded…
I'm not that intimate with Webpack, but it makes sense the way you broke it down 👍 (use ava-loader and AvaPlugin). I understand that the ultimate goal would be for Webpack users to be able to seamlessly integrate this into their configuration and receive test results for each compilation?
Looking at extract-text-webpack-plugin and html-webpack-plugin, it's possible to dynamically create entry chunks. I think what one could do is optimize at the end, extracting all AVA modules from chunks, putting them into a distinct chunk and then run the tests. This would probably let a Webpack user with multiple entry points to run a development server and tests (without having to write an entry point that collects tests from all the other entry points, so they're at the liberty to organize their tests without worrying on how they're going to be discovered and bundled for AVA).
This sounds like something that could be explored outside of AVA itself. Any resulting plugins we'd happily make "official".
The webpack recipe was also updated recently, though it doesn't discuss extracting AVA itself into a separate chunk. Further improvements to the recipe are most welcome!
We could look at https://www.npmjs.com/package/@mzgoddard/jest-webpack for inspiration.
Using Webpack's context, you can dynamically load in modules with the name **/*.test.js on the fly:
https://github.com/Sawtaytoes/Ghadyani-Framework-Webpack-React-Redux/blob/master/src/tests.js#L10
I started using AVA on some Node.js projects, and am wanting to switch to AVA from Tape in my React projects. I haven't yet found a way to run it on my Webpack-built code. Since I run Webpack through the Node.js API methods, I can't pipe a config through the CLI to AVA like the Webpack Recipe; I'd have to run two completely separate CLI instances and would lose out on browser debugging.
The benefit of running tests in the browser with Webpack is I get easy debugging exactly as if I was running the React app itself.
Is this still an option that might come in the future?
Is this still an option that might come in the future?
@Sawtaytoes yes, but it's not a priority.
Is it my understanding this is in now?
https://github.com/avajs/ava/blob/master/docs/recipes/precompiling-with-webpack.md
@Sawtaytoes not sure. I don't think that recipe has changed much since you're question from September.
This sounds like something that could be explored outside of AVA itself. Any resulting plugins we'd happily make "official".
The webpack recipe was also updated recently, though it doesn't discuss extracting AVA itself into a separate chunk. Further improvements to the recipe are most welcome!
That webpack recipe is a broken link now...
@glenndevenish yea it's been removed. IIRC because it had gotten too outdated.
So what's the state of using webpack with Ava? I see an example here:
https://github.com/kusotenpa/karma-vs-ava/blob/master/webpack.config.ava.js
Which is just running webpack beforehand then running ava after. Is that sufficient? I'm testing a Vue.js app which originally used karma + rails/webpacker and looking to replace it with ava.
The documentation for webpack seems non-existent within the project and that confuses me... is the idea ava does all the compilation instead of webpack?
@dmix there is nothing in AVA specifically to support Webpack, insofar as anything specific is required.
You'd somehow need to run a Webpack build, and then load that code from your tests. I'm not sure what that entails, I don't do front-end development.