Would it be possible in any way, to run Karma/Jasmine tests in two-step approach:
First step preprocesses all application files (Babel, Webpack, coverage, source maps, etc.) and stores the preprocessed output.
Second step runs actual (Jasmine) tests on files already preprocessed in first step.
?
This way we could preprocess all application code once and run second step as many times as we want (of course assuming that we don't change application code after running step 1).
Edit:
Some more details:
app code is divided into modules: common, moduleA, moduleB, ...
there is a single karma.conf.js with preprocessors set up to handle entire code base
Grunt is used to run karma tests - there are separate tasks to run tests only for given module (given Grunt task adjusts files section of Karma config to load only test specs for module that is to be tested)
On CI we test each module separately - running all tests in one go crashes the browser (due to excessive memory use - we've had little success in fixing this). So Karma runs n times (n is number of modules) preprocessing entire code base each time and running tests only for module that's currently being tested.
Since actual code (neither app or specs) does not change while modules are being tested one-by-one our idea was to tell Karma to only preprocess entire code base at first. Afterwards we could run Karma on each module using the previously preprocessed code. This should be much faster than what we currently have.
By the way, this is an Angular app. Tests are based on Jasmine and use ngDescribe.
Related
Problem
I'm writing several test suites (using Jest and Puppeteer) to automate tests of my AngularJS app's home page. At this point, I have nearly 70 tests in one of my test files (aka test suite). And I'm wondering if it's possible to pass an array of test names to Jest's -t option to run a specific subset of tests in one of my test files. This will be helpful for debugging, as I have some tests that are interdependent and thus always need to be run together, but it would be nice to avoid having to run the entire test suite (which runs in about a minute) every time I want to debug a few tests.
Overview of my testing environment:
Puppeteer version: 1.19.0
Jest version: 24.8.0
Jest commands I've tried
I've been reading the Jest docs and so far I've come across a few CLI options that have the potential to solve this problem, but have not been fruitful so far.
jest name-of-test-file.spec.js: This runs all the tests in a single test file, but I don't want to do that, I just want to run a specific subset of tests in a test file.
jest name-of-test-file.spec.js -t name-of-test: This only runs a single test in a test file, but I want to run a few different interdependent tests.
jest name-of-test-file.spec.js --testPathPattern=<regex>: This runs all the tests whose names match the regex pattern I pass. It could be helpful but so far I haven't been able to come up with a valid regex that matches against three unique strings (i.e. test names). Unfortunately my test names differ greatly so it would be hard for me to come up with a more generalized regex to match the specific tests I want to run.
Final thoughts/ question:
I think option 3 has the most potential, but I haven't been able to find a working regex.
If the regex option does not work for you, you can use it.only (or test.only) to only run specific tests inside a module.
Quote from the docs:
When you are debugging a large codebase, you will often only want to run a subset of tests. You can use .only to specify which tests are the only ones you want to run.
Code Sample
it.only('This test will run', /*... */);
it.only('This test will also run', /*... */);
it('This test will not run', /*... */);
However, you still need to specify which module or file to run in case you are having multiple test files:
jest name-of-test-file-to-run.spec.js
we have a rather big/long-grown angular project. It currently runs angular 1.2 (we are in the process to upgrade to angular 1.5 and start preparing the angular2 migration).
To be able to start the angular2 migration, we want to integrate typescript into the project. The integration for the source files was quite easy. We use browserify; we just added tsify and some configs and everything worked within minutes (js+ts code/modules get bundled together).
For our frontend unit tests (karma, jasmine) its quite the opposite (working on that for hours now).
Here is our karma config:
https://gist.github.com/ds82/2eaeae875eef92481bc699ead8a7ac5c
If I run our test suite with this config, the typescript spec files are just ignored completely. The tests nor the code inside these typescript files is executed at all (have console.log at the top of the spec.ts files).
Browserify logs that it includes the typescript files, but if I open the karma debug browser view and try to open the source of the spec.ts files Chromes shows me just an empty file. While I'm doing this it logs:
28 06 2016 16:25:35.242:WARN [web-server]: 404: /absolute/var/folders/0p/b7pdm54d26q8db2qsxtxb3z80000gn/T/app/scripts/blobb.spec.ts
Now, if I comment out line 49 and line 50 of the karma config (which results in only loading the spec.ts files an no spec.js files), the typescript tests run just as expected. At the same time, I can view the spec.ts files in the karma debug browser view.
To summarise: If I run all tests (javascript + typescript), just the javascript files/tests are executed. If I disable/comment-out all javascript tests, my typescript tests run fine.
Does anybody has an idea how I could find the cause of this?
Found a workaround here: https://github.com/angular/angular-cli/issues/2125#issuecomment-247395088
I figured out a work around. In the karma.conf.js file, add:
mime: {
'text/x-typescript': ['ts','tsx']
},
This tells the Karma server to serve the .ts files with a text/x-typescript mime type. That seems to make it work.
I had the same issue and found that Chrome had an error in the console about an invalid MIME type for my Typescript file. The file still has a .ts extension, so it's interpreted as a video file. The workaround tells Karma to serve it with the right MIME type.
It seems like maybe using karma-typescript would avoid this issue by serving the file with .js, but I wanted to keep the same browserify/tsify setup that we are using for regular source files.
I have homework JS code to check every week.
I have tests for JS logic, but i also has a requirement for overall size and file quantity.
So i was wondering is there any possibility to write tests (i assume mocha - because it runs on node, and has access to FS) for folder size and file count in folder (also has a limit)?
I have no experience in Mocha or Node, so should i dive deeper?
I'm not quiet sure what you are asking, but:
Mocha is a framework to run "unit tests" to test the software you have written and see if it's working ok.
If you just want to count some files in a directory you don't need a testing framework. Just use node's normal filesystem classes in fs https://nodejs.org/api/fs.html to write your code.
If you want to check that files maybe you are talking about integration test and not unit test. So, I believe that if you want to make unit test you will need read something about mock's and stub's. You can search modules like sinon. A few weeks I was fighting with test that checks if dirs or files are created and I reached the conclusion that if I want to make unit tests I need that module. Here's Sinon
I just came into a Node.js project that has a ton of unit tests, most of which, unfortunately, are outdated and don't run. There's no test runner or any kind of code coverage tool implemented, and it is certainly not in my scope of work to refactor everything.
That being said, that doesn't stop me from wanting to check the code coverage of my work. I've looked at both Istanbul and Blanket and can't find a way to only have them run certain unit tests. Surely, there is a way so that I can get a report that, obviously, reports a very low percentage of coverage, but that I can dive into certain files and such (those that my tests hit) to ensure my code is throughly tested.
With istanbul.js, you can easily get the coverage information this by for example specifying the following command (Following example uses mocha but it will be similar for any test framework):
istanbul cover node_modules/.bin/_mocha -- -u exports -R spec test/test1.spec.js test/test2.spec.js
You can also specify all the tests in particular sub-directory eg: test/yourfeaturetest/*.spec.js. You also have something like test/myfeature/**/*.spec.js to cover all the tests in the test/myfeature directory including tests that could have been created recursively in sub-directories.
As for me, I use gulp and thus utilize plugins such as gulp-istanbul and run tests and coverage via gulp tasks.
I have an browser javascript app which uses browserify and Mocha tests which are run in Phantom.js and other browsers.
The tests use a test/tests.js file as an entry point where I require each file:
// ...
// Require test files here:
require('./framework/extendable.test');
require('./framework/creator.test');
require('./framework/container.test');
require('./framework/api_client.test');
// ...
This is very tedious and I would like to be able to require the entire folder.
I have tried using include-folder which only loads the contents of each file (I don´t want to eval for obvious reasons).
I have also looked at require-dir but Browserify does not seem to pick up on the require calls.
You can use Karma (https://github.com/karma-runner/karma) to run your Mocha tests in multiple browsers (PhantomJS, FF, IE, locally or remote via WebDriver, as you want).
Then you can use the karma-bro (https://github.com/Nikku/karma-bro) preprocessor. It will bundle your tests on the fly with browserify, only for the testing purposes.
So you can just specify the folder, that contains your tests, in the Karma config.
That's the way I do it.
You could also write your own simple transform that will simply replace specified folder name with the list of require calls. Even with the random in place if necessary. It's not that hard. I am making many transforms for myself to ease up on stuff like this.