I would like to create a test suite which will be run with karma against my app which is using webpack to build itself. I have two entrypoints, app and vendors. These are set up through my webpack.config.js file here. The resulting bundle.js should contain both of these entrypoints in its generated file.
My karma (mocha) tests residing in test/spec/*_spec.js are currently pointing to specific components, via require statements like:
var app = require('../src/scripts/App')
They also utilize react/jsx which seems to be causing problems during the test run where I get jsx errors:
Module parse failed: /Users/dmarr/src/status/test/spec/app_spec.js Line 10: Unexpected token <
You may need an appropriate loader to handle this file type.
I'd like to keep test runs quick as possible as well as fast build times for testing with webpack-dev-server during development by minimizing babel transforms to only where needed.
What do I need to do in karma.conf.js to get my builds working? Here is the karma.conf.js file I'm playing around with.
Note, that I do have this working without breaking out the vendor bundle here: https://github.com/bitwise/status
Thanks for any help,
Dave
In a similar setup, disabling CommonsChunkPlugin (for testing only) worked for me. Give it a shot!
Related
i've got a karma-webpack2-qunit setup with babel loader working. es6 is used for both src and test js files.
when running karma in autowatch mode, any changes to source files are detected and karma re-runs the test suite again but the changes are not picked up.
based on this note from the webpack-karma integration page: webpack-karma middleware info , this seems like the config option i need to get the setup fully working.
"This loader provides a webpackBlocker middleware that will block tests from running until code recompiles."
i can't find any examples of using the webpackBlocker configuration.
does someone have a working config they can share?
here's what i'm using in karma.config.js:
the karma test suite is working still but code changes to source or test code do not get reflected in the next run.
i finally got this working. had a mismatch in my "files" pattern config for my test and source files including the "context" object.
now when i modify either test or source js files, the code is compiled first and the tests are rerun in autowatch mode. yay !!!
will post the full working solution to a GitHub repo in case anybody else wants to get the same "unholy" :-) combination (karma + qunit + webpack + es6 + mocha reporter + phantomjs) working. will also add linting.
The documentation for Sails 0.12.11 explains how to set up testing using the Mocha framework. I would like to use Jest to do that.
I tried using the same code for bootstrap.test.js, but replacing before with beforeAll and after with afterAll; replacing this.timeout(5000) with jasmine.DEFAULT_TIMEOUT_INTERVAL = 5000. Because Jest expects at least one test in a file, I made a dummy test there to make sure it did not complain.
Then, in another file (some.test.js), I tried to reference a dummy service that I created just to see if things work. With Mocha, any Sails service should be available by default, without any require statement.
it('should call the dummy service fine', () => {
expect(DummyService.doSomething()).toBe('ok');
});
Upon running the tests with jest tests/*, I come across the following log:
Furthermore, the dummy service test fails because it says it is not defined.
FAIL tests/some.test.js
● should call the dummy service fine
ReferenceError: DummyService is not defined
Jest does seem to be well suited to tests sails.
Jest philosophy is to have many tests running concurrently with independent state this means jest has no way to use global setup file.
Using jest for sails would mean :
Starting an instance of sails per test which could be memory hungry if you've got many test.
Customize its orm (waterline) so that it uses a random file for the database for each test instance to accomplish clean state.
Now you may argue that sails does it wrong and could be made from the startup to support the kind of testing jest promote.
I hope this is still relevant.
I won't lie you. It was not easy :(. It took me all the day but after all I was able to configure
Eslint
Prettier
Jest
check how it all works in my repo and feel free to contact me if you have any doubt.
https://github.com/tugorez/sails-jest
I want to support the usage of 'debugger' statements locally and on the development deployment but not when it gets to staging or production.
I'm using Ember-cli with environments and am not understanding how to define the jshint or eslint directives differently.
By design we can configure both linting libraries differently via their configuration files for app code & test code via .eslintrc or .jshintrc files which reside at the root folder and the tests folder. So even though we can have different rules for these categories of code, we can't differentiate them per environment.
The reason it might not make sense to do so is because the assets that get generated after the build process that gets deployed doesn't necessarily need to conform to these rules since transpilers like babel (may) optimize generated code for us.
While I don't understand the need to keep debugger statements after a debugging session in the codebase, you can use broccoli-strip-debug to remove them automatically in production builds and disable the debugger flag in the linting configuration altogether which gets you the setup you're looking for.
I want to set my Grunt.js file to launch my MAMP server on grunt serve.
I have been trying to use this tutorial here to do this:
https://coderwall.com/p/kwne-g
I was then planning to use this tutorial to set up grunt watch:
http://darrenhall.info/development/yeoman-and-mamp
Now I am having trouble with step one. I have successfully installed grunt exec. However, grunt claims not to be able to find the task 'serverup'.
Here is my code:
grunt.task.run([
'clean:server',
'concurrent:server',
'autoprefixer',
'connect:livereload',
'serverup',
'watch',
'serverdown'
]);
If you followed the examples at the link, it looks like your targets should be exec:serverup and exec:serverdown for the tasks to work.
The problem here and with many other Grunt related questions is that without the full Gruntfile, "answers" are largely guesses. Configuration, task loading, and task registration are all related and without seeing all three, it is difficult to say "this is the answer".
Given that, here's a checklist I use for problems like this when using Grunt and packages from NPM:
Is the code that supports the task installed? Did I forget npm install? Did I miss
errors on install (check npm-debug.log if it exists)?
Have I correctly used grunt.loadNpmTasks for the plugin? Is the line in my Gruntfile and
did I get the plugin name spelled correctly? Did I or my IDE accidentally use to
grunt.loadTasks when I need loadNpmTasks?
Have I correctly named/used grunt.registerTask for the task? If I need to call a
specific target for a task, do I have the the name correctly specified?
If there are paths involved and things are broken, do I have my globbing patterns correctly specified? If a cwd
is involved, do I have the other paths or files correctly specified?
Did I get the configuration right? (This is where things get too plugin-specific for a
checklist.)
I've used Yeoman to make a quick project skeleton using the yo webapp generator command. In the resulting Gruntfile I see that it's setup to compile CoffeeScript but it seems like its just sticking compiled files in a tmp folder.
coffee: {
dist: {
files: {
'.tmp/scripts/coffee.js': '<%= yeoman.app %>/scripts/*.coffee'
}
},
},
How do these get included in the project during development. I'm not using RequireJS.
The yeoman docs are unclear on how to use coffeescript. They only mention that it gets automatically compiled.
Using yeomen 1.0.0-rc1.4. I use:
$ yo angular --coffee
The resulting project has controller and app scripts in CoffeeScript.
grunt configuration file remains in js (what is not really a problem).
Running
$ grunt test
runs tests and all seems fine.
$ grunt server
is also doing what one expects (build the app, test it, starts server, opens the app in web browser and starts watching for changes, so if I change a coffee script file, it is quickly reflected in the web broser.
Documentation also states, one can use yo to add particular pieces like
angular:controller
angular:directive
angular:filter
angular:route
angular:service
angular:decorator
angular:view
each can be called with a --coffee switch and get the script in CoffeeScript, e.g.:
yo angular:controller user --coffee
I just found an issue in the github repo referencing this problem. https://github.com/yeoman/generator-webapp/issues/12
It offers a temporary solution: https://github.com/yeoman/generator-webapp/issues/12#issuecomment-13731929