GitLab Pipeline not able to parse double-dash in npm script property - jestjs

I am using stencil for building custom web components.
For testing, stencil is using jest CLI for running test files, here is the npm script command Im currently used for running those tests locally:
{
"test:base": "stencil test --spec --e2e",
"test:all": "npm run test:base -- --coverage"
}
It is working perfectly when I am running it locally and the parameter --coverage in script test:all after double-dash can be parsed correctly:
$ npm run test:base -- --coverage --silent
> #heartlandone/vega#1.1.20 test:base
> stencil test --spec --e2e "--coverage" "--silent"
[59:13.9] #stencil/core
[59:14.1] v2.14.0 💫
[59:14.2] testing e2e and spec files
[59:16.3] build, vega, dev mode, started ...
[59:16.8] transpile started ...
[59:18.3] transpile finished in 1.45 s
[59:18.3] copy started ...
[59:18.3] generate lazy started ...
[59:18.5] copy finished (17 files) in 210 ms
[59:21.0] generate lazy finished in 2.76 s
[59:21.2] build finished in 4.91 s
[59:21.2] jest args: --coverage --silent --e2e --spec --max-workers=8
...
✨ Done in 36.94s.
However when I run it in gitlab pipeline:
> npm run test:base -- --coverage --silent
> #heartlandone/vega#1.1.20 test:base /builds/heartland1/vega/tiger/vega-stencil
> stencil test --spec --e2e "--coverage" "--silent"
[12:42.1] #stencil/core
[12:42.5] v2.14.0 💫
[12:42.9] testing e2e and spec files
[12:51.4] build, vega, dev mode, started ...
[12:51.6] transpile started ...
[12:55.6] transpile finished in 3.99 s
[12:55.6] copy started ...
[12:55.6] generate lazy started ...
[12:56.1] copy finished (17 files) in 516 ms
[13:08.8] generate lazy finished in 13.23 s
[13:08.9] build finished in 17.55 s
[13:09.0] jest args: --coverage --silent -- --e2e --spec
--max-workers=8
No tests found, exiting with code 1
Seems like somehow the double dash is passed into jest directly hence making jest assuming --e2e and --spec is some keyword of the test suite hence filtering out all the existing test suites supposed to be run.
Not sure if this is a known issue or something can be resolved from user side?

I experienced a similar problem in a monorepo project where I'm using nx and pnpm.
My problem
I observed the following behaviour:
When cding into the Stencil project and running pnpm test, the tests ran as expected.
When running nx run stencil-project:test no tests were found.
Investigation
Having a closer look the following happens:
When running the second command, a double-dash was added to the final Stencil command: stencil test --spec --e2e "--".
Stencil pushes all unknown args to Jest, see https://github.com/ionic-team/stencil/blob/main/src/testing/jest/jest-config.ts#L49
Unfortunately for that reason Jest receives the following command: jest --max-workers=8 -- --e2e --spec --max-workers=8
And now the problem happens: Everything after the double dash is used as the pattern --e2e|--spec|--max-workers=8 to filter tests by their name.
As the pattern of course doesn't match any test, they get filtered out.
Screenshot of final Jest error
"Solution"
❌ I started writing a Stencil-PR to remove the first -- in the args, but I wasn't sure if NX or Stencil is to blame and therefore dropped it.
❌ As an alternative I tried to ran Jest manually by recreating Stencil's Jest-config but unfortunately that didn't work out in the end. If someone would provide a solution for that, this would be better.
✅ As it's super hard to influence Stencil's mechanisms (drawback of it being so opinionated) in the end I used a dirty hack: I added '*' to my test-scripts in package.json:
{
"test": "stencil test --spec --e2e '*'"
}
This breaks the pattern and instead runs all tests (Invalid testPattern *|--e2e|--spec|--max-workers=8 supplied. Running all tests instead.)
🎉 Mission accomplished. I hope this helps you, too.

Related

Jest.config settings modulePathIgnorePatterns and testPathIgnorePatterns aren't having any effect

I'm running tests in a node app using jest. I can get tests running properly, but I can't seem to tell jest to ignore directories. For example, when I try to test a specific file convertExistingImages.ts with the command: npm test convertExistingImages I get a response in my terminal of:
> mfa-bot-2022#1.0.0 test
> jest
FAIL dist/utils/maintenance.ts/convertExistingImages.test.js
● Test suite failed to run
Your test suite must contain at least one test.
(...)
FAIL src/utils/maintenance/convertExistingImages.test.ts
● Test suite failed to run
(...)
As you can see, a duplicate file in my /dist folder is also being tested, which I don't want.
I've tried updating my jest.config.ts file as follows:
module.exports = {
"preset": "#shelf/jest-mongodb",
"modulePathIgnorePatterns": ["/build/"],
"testPathIgnorePatterns": ["/node_modules/", "/build/"]
}
But the modulePathIgnorePatterns and testPathIgnorePatterns settings aren't having any effect.
Can anyone tell me what I'm doing wrong?
You configured it to ignore the build folder but your conflict is in the dist folder. Change build to dist in your ignore settings.
You can read more about this config on the Jest site here.

How to setup mocha to run unit tests first and then start a server and run integration tests

I have unit tests and integration tests that need to be run with one 'npm run mocha' command. The suite before my integration tests was set up and working properly with mocha.opts including the before step like so:
test/beforeTests.js (sets up some important variables)
test/*.x.js (bulk of the tests, all the files ending in .x.js are run)
When including my integrations tests, a unit test fails because the running server clashes with some stubbed functions. Therefore I wanted to run unit tests first, then star the server, run integration tests and close the server. Which I have tried by changing mocha.opts to:
test/beforeTests.js (sets up some important variables)
test/*.x.js (bulk of the tests, all the files ending in .x.js are run)
test/startServer.js (start the server)
test/integration/*.x.js (run integration tests)
test/afterTests.js (close the server)
beforeTests.js:
before(function(done) {
// do something
});
startServer.js:
before(function() {
return runServer()
});
both beforeTests, and startServer work however they are both executed in the beginning of the test instead of
beforeTest > do unit tests > start server > do integration tests > stop server
I cannot merge the integration tests in one file, or the unit tests as there are too many. Is there a way to set up mocha.opts to do what I want. I've looked around and nothing really fits what I want to do.
One of technique that I use before for this is to have two npm commands for unit and integration test then combine them in one npm command if I want to run them in single execution.
"test": "npm run test:unit && npm run test:integration"
"test:unit": "mocha test/unit",
"test:integration": "mocha test/integration"
You can start server as part of integration test.
I suggest to use test for npm test instead of mocha for npm run mocha because it is more standard test command name in node project.
Hope it helps

Setting up Angular Universal App for development

I have created a project with Angular-CLI. (using command: ng new my-angular-universal).
Then I carefully followed all the instructions from https://github.com/angular/angular-cli/wiki/stories-universal-rendering
It builds for --prod and works fine. But there are no instructions on how I can set up a --dev build and have it served with --watch flag.
I tried removing --prod flags from npm "scripts", and it doesn't even run in dev mode. It builds fine but when I open it in browser this is what I see (directly printed to response):
TypeError: Cannot read property 'moduleType' of undefined
at C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:7069:134
at ZoneDelegate.invoke (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:105076:26)
at Object.onInvoke (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:6328:33)
at ZoneDelegate.invoke (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:105075:32)
at Zone.run (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:104826:43)
at NgZone.run (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:6145:69)
at PlatformRef.bootstrapModuleFactory (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:7068:23)
at Object.renderModuleFactory (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:52132:39)
at View.engine (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:104656:23)
at View.render (C:\Users\Mikser\documents\git\my-angular-universal\dist\server.js:130741:8)
the versions of npm packages that I use are currently the latest:
#angular/* - #5.2.*
#angular/cli #1.7.3
except for ts-loader, had to downgrade it because it wasn't working:
ts-loader #3.5.0
So if anyone has any info on how to make this work, it would be very appreciated! Or maybe you know some project templates with Angular Universal App configured for both --dev and --prod builds and ability to --watch?
For development, run npm run start which triggers ng serve. The current setup has hot module reloading so it will watch for your changes and update your dev view. I used the same instructions and got it working here https://github.com/ariellephan/angular5-universal-template
In short, for development, run npm run start and look at http://localhost:4200.
For production, run npm run build:ssr and npm run serve:ssrand look at http://localhost:4000
As contributors have pointed out, it might not be the most efficient and fastest way to develop, but nevertheless I did not want to accept workarounds. Besides, hosting front and back on separate servers brings up CORS issues, and I never planned my app to run on separate hosts, I wanted it all on the same host together with API methods.
The problem with --dev build was this:
when building with the following command:
ng build --app 1 --output-hashing=false (note that there is no --prod flag)
AppServerModuleNgFactory turned out missing in the ./dist-server/main.bundle
I imagine that this relates to the ahead of time(--aot) compilation which is the default behavior if you are building for --prod. So the instructions from https://github.com/angular/angular-cli/wiki/stories-universal-rendering included instructions to configure express server for production build only. And since there is no need for server to be able to dynamically render html templates the working --dev build command would be:
ng build --app 1 --output-hashing=false --aot
and this gets rid of the TypeError: Cannot read property 'moduleType' of undefined
Now to watch this whole mess:
run these in separate command windows:
ng build --watch
ng build --app 1 --output-hashing=false --aot --watch
webpack --config webpack.server.config.js --progress --colors --watch
And for the server to restart on change, you have to install nodemon package and run it like this:
nodemon --inspect dist/server (--inspect if you wish to debug server with chrome)
Some other important stuff:
Angular/CLI has a command to generate necessary scaffolding for a universal app:
ng generate universal
and it generates a fixed version of main.ts that avoids client angular bootstrap issue:
document.addEventListener('DOMContentLoaded', () => {
platformBrowserDynamic().bootstrapModule(AppModule)
.catch(err => console.log(err));
});
a problem that I stumbled upon once I implemented TransferState
There are basically two parts - the server and the UI. While developing the UI, I simply use ng serve. That means when I make changes in my code in the IDE, the browser refreshes automatically. And, here the server part is not used.
I do prod build and run the server only for final testing to see if everything works as expected (No error due to any 3PP library DOM manipulation or AOT related issues, etc.)
Here, I have created a skeleton structure of an Angular Universal project. As I extensively use Vagrant and Docker in my projects, I run the server in a Docker container within the Vagrant guest system. And for development of the UI, I don't run the server. Simply, the ng serve is used.
If you look into my structure in the above Github link, you'll find the details as to how to run it for development and production in the Readme file.
The web server handler server.ts uses the server bundle
const { AppServerModuleNgFactory, LAZY_MODULE_MAP } = require('./dist/server/main.bundle');
That's why the server bundle needs to be compiled before you can compile the server.ts file.
So having a watch system would mean
watching/recompiling the client bundle
watching/recompiling the server bundle
recompiling the server.ts once the server bundle is created
All of them take some time (especially if you do it with aot)
I'd recommend, like Saptarshi Basu mentionned, to develop as best as you can with ng serve and check with angular universal every so often.
Otherwise, it should be possible do achieve what you want with some kind of tasks (grunt/gulp/...) which triggers sequentially ng build ... and recompilation of server.ts file.
It is a bit messy no doubt, as we preferably wish for one command to rule them all.
I came up with a somewhat OK solution where my output will be:
dist/browser
dist/ng-server
Using the executable npm-run-all package (I find it working a lot better on windows machines than concurrently does) I run the three watch tasks: browser, ng-server and nodeJS. Watching node has a pre-task defined that simply runs a small utility/helper/file that watches for the existence of a dist/ng-server folder and terminate itself once found.
For all of this to work (based on the universal-starter repo as of november 2018) there's a couple of modifications to package.json required. Primarily, to support the --watch flag on ng run commands we need to update the compiler-cli (if memory serves), ng update --all should take care of that, giving you the latest angular/cli version in the process (assuming you have a recent cli version installed globally).
package.json
ng update --all
angular 6+
angular/cli 7+
yarn add/npm install the following
chokidar
npm-run-all
(runs our tasks in parallel with the -p flag. -p kills all processes, -l gives each running task a specific color and name in the console)
ts-node (runs nodejs in it's ts-format)
nodemon // for restarting ts-node
add something similar to my util/await-file.js (after some consideration I added my own file-watcher code below even though it wasn't exactly written with the intentions to be put up on display...)
modify your package.json scripts like below
modify your angular.json to match your folder names, following my examples, mainly the "server"'s outputPath should be changed from dist/server to dist/ng-server.
package.json scripts
"dev": "npm-run-all -p -r -l watch:ng-server watch:browser watch:node",
"watch:browser": "ng build --prod --progress --watch --delete-output-path",
"watch:ng-server": "ng run ng-universal-demo:server --watch --delete-output-path",
"watch:node": "yarn run watch:file-exist && yarn run ts-node",
"ts-node": "nodemon --exec ts-node server.ts -e ts,js",
"watch:file-exist": "node utils/await-file.js",
util/await-file.js
const chokidar = require('chokidar');
const fs = require('fs');
const path = require('path');
const DIR_NAME = 'ng-server';
const DIST_PATH = './dist';
// creates dist folder if it doesn't exist - prior to adding it to the watcher.
if (!fs.existsSync(DIST_PATH)) {
fs.mkdirSync(DIST_PATH);
}
const watcher = chokidar.watch('file, dir', {
ignored: '*.map',
persistent: true,
awaitWriteFinish: {
stabilityThreshold: 5000,
pollInterval: 100
}
});
const FOLDER_PATH = path.join(process.cwd(), 'dist');
watcher.add(FOLDER_PATH);
console.log(`file-watcher running, waiting for ${DIST_PATH}/${DIR_NAME}`);
function fileFound() {
console.log(`${DIR_NAME} folder found - closing`);
watcher.close();
process.exit();
}
watcher
.on('add', function (filePath) {
const matchWith = path.join('dist', DIR_NAME);
const paths = filePath.split(path.sep);
const fileName = paths[paths.length - 1];
if ((filePath.indexOf(matchWith) >= 0)
&& fileName.indexOf('.js') > fileName.length - 4) {
fileFound();
}
})
.on('error', error => console.log(`Watcher error: ${error}`));
"npm run start" and using "http://localhost:4200" works for me. Even with Angular 10

Run "node test" as part of Visual Studio Team Services build task with results in "tests" tab

I have a project that contains tests that I am running with Mocha from the command line. I have set up a test script in my packages.json, which looks as follows:
"test": "mocha ./**/*.spec.js --reporter dot --require jsdom-global/register"
I have currently got a simple task set up in Visual Studio Team Services, which just runs the npm test command, this runs Mocha within a console and continues/fails the build depending on whether the tests pass.
What I'd like to be able to do is have the results of my tests populate the "tests" tab in the build definition after it's run. In the same way that I can get this tab populated if I'm running tests on C# code.
I've tried using Chutzpah for this, but it's overly complicated and seems to require that I jump through all sorts of hoops that mean changing my tests and writing long config files. I already have loads of tests written, so really don't want to have to do that. When it did finally discover any of my tests, it complained about require and other things related to Node modules.
Is what I'm asking for actually possible? Is there a simple way of achieving this that's compatible with running my tests in Node?
I've found a good way of doing it that requires no third-party adapter (eg. Chutzpah). It involves getting Mocha to output its report in an XML format, and setting up Visual Studio Team Services to publish the results in an extra step of the build definition.
I installed mocha-junit-reporter (https://www.npmjs.com/package/mocha-junit-reporter) and altered my test script to the following:
"test": "mocha ./temp/**/*.spec.js --reporter mocha-junit-reporter --require jsdom-global/register"
I then created a new step in my build definition using the "Publish Test Results" task. I set the result format to "JUnit" and added the correct path for the outputted test-results.xml file created by the reporter.
It is worth noting that although Mocha comes with an "XUnit" reporter, this format appears to not work correctly with VSTS even though it's listed as an option.
The results of npm test now show up in the "tests" tab alongside any other tests from MSTest etc.
I'm using karma and got this to work in the same way as #dylan-parry suggested. Some excepts below in case it helps others:
package.json
"scripts": {
"test": "cross-env NODE_ENV=test karma start"
}
karma.conf.js
const webpackCfg = require('./webpack.config')('test');
module.exports = function karmaConfig(config) {
config.set({
reporters: ['mocha', 'coverage', 'junit'],
junitReporter: {
outputDir: 'coverage',
outputFile: 'junit-result.xml',
useBrowserName: false
}
})
...
TFS
It may also be worth adding I'm using branch policies on my git branch to prevent PR's being merged if the tests fail, info via this link:
https://www.visualstudio.com/en-us/docs/git/branch-policies
Here's the output in TFS:
Next step is to get the coverage working too!

Separation of unit tests and integration tests

I'm interested in creating full mocked unit tests, as well as integration tests that check if some async operation has returned correctly. I'd like one command for the unit tests and one for the integration tests that way I can run them separately in my CI tools. What's the best way to do this? Tools like mocha, and jest only seem to focus on one way of doing things.
The only option I see is using mocha and having two folders in a directory.
Something like:
__unit__
__integration__
Then I'd need some way of telling mocha to run all the __unit__ tests in the src directory, and another to tell it to run all the __integration__ tests.
Thoughts?
Mocha supports directories, file globbing and test name grepping which can be used to create "groups" of tests.
Directories
test/unit/whatever_spec.js
test/int/whatever_spec.js
Then run tests against all js files in a directory with
mocha test/unit
mocha test/int
mocha test/unit test/int
File Prefix
test/unit_whatever_spec.js
test/int_whatever_spec.js
Then run mocha against specific files with
mocha test/unit_*_spec.js
mocha test/int_*_spec.js
mocha
Test Names
Create outer blocks in mocha that describe the test type and class/subject.
describe('Unit::Whatever', function(){})
describe('Integration::Whatever', function(){})
Then run the named blocks with mochas "grep" argument --grep/-g
mocha -g ^Unit::
mocha -g ^Integration::
mocha
It is still useful to keep the file or directory separation when using test names so you can easily differentiate the source file of a failing test.
package.json
Store each test command in your package.json scripts section so it's easy to run with something like yarn test:int or npm run test:int.
{
scripts: {
"test": "mocha test/unit test/int",
"test:unit": "mocha test/unit",
"test:int": "mocha test/int"
}
}
mocha does not support label or category. You understand correctly.
You must create two folders, unit and integration, and call mocha like this
mocha unit
mocha integration

Resources