Running Chutzpah 3.2.2.0 from command line all tests are discovered and executed in about 40 seconds, which I think is a good speed for more than 100 unit tests split into several files:
chutzpah.console.exe path\to\MyProjectRootFolder\chutzpah.json
However, in Visual Studio, it takes 9-10 minutes for the list of tests to be loaded in Test Explorer.
Monitoring VS with Process Explorer, I noticed that the process "vstest.discoveryengine.x86.exe" is calling phantomjs.exe several times during the discovering process.
My understanding was that Chutzpah would require PhantomJS to execute the tests in a browser context, and only for tests execution. Maybe I am misunderstanding the process here.
My chutzpah.json file:
{
"Framework":"qunit",
"TypeScriptCodeGenTarget":"ES5",
"TestFileTimeout":"60000",
"Compile": {
"Extensions": [
".ts"
],
"ExtensionsWithNoOutput": [
".d.ts"
],
"Mode": "External"
},
"CodeCoverageExcludes": [
"*ests.ts",
"*ests.js"
],
"Tests": [
{
"Path": "TestsSubfolder", "Include": "*.ts"
}
]
}
Is there any settings to tell Chutzpah: "hey buddy, I just need a list of tests loaded in VS Test Explorer, no need to compile or run them now."?
Chutzpah uses PhantomJS for both test execution and test discovery. In order for Chutzpah to know what tests exist it must run them in discovery mode (where it run the file but tells the test framework to not execute the bodies).
That said, it should not take that long in VS. It should be as fast as when you run them. Can you please file a bug on chutzpah.codeplex.com with a repro and I will take a look.
Related
After running Hardhat tests in the console with npx hardhat test I decided that being able to set break points would help me iterate faster.
How can I get Webstorm to run the underlying functions started by npx hardhat test so that I can use the built in Debugger?
I've since discovered that hardhat runs mocha under the hood.
To debug in WebStorm you can:
delete your existing configurations
create a new mocha configuration
set any configurations in 'Node options'. Note: since I'm forking the main net it takes a while for tests to start so I added the --timeout 10000 because mocha's default timeout is only 2000ms
select the mocha package, WebStorm doesn't select it by default
set your test file pattern
add const {ethers} = require('hardhat'); to your test file because it is no longer injected by hardhat during run time.
If the green debug icon does not appear I had success in closing and reopening WebStorm.
At this point I could successfully set break points in my test file but not in the MyContract.sol file. This is not surprising given that the contract is compiled before its run.
Create or open the package.json file for your Hardhat project.
Add a test NPM run script and save the file. Your package.json should look something like this.
{
"name": "hardhat-project",
"scripts": {
"test": "hardhat test"
},
"devDependencies": {
"#nomiclabs/hardhat-ethers": "2.0.2",
"#nomiclabs/hardhat-waffle": "2.0.1",
"chai": "4.3.4",
"ethereum-waffle": "3.4.0",
"ethers": "5.4.4",
"hardhat": "2.6.0"
}
}
In the left gutter of the editor pane, a little play icon should appear, click it and then click Debug "test".
I go through the instructions in a little more detail here, but this is the general idea. https://allendefibank.medium.com/how-to-debug-solidity-contracts-in-webstorm-hardhat-2ea0d3c4d582
If you're use typescript you need to import ts-mocha instead of mocha
I have a simple LinkedList implementation in Node. I want to test it using Mocha -- simply exercise different append/delete operations. And most importantly, I want to be able to stepthrough/debug my linkedlist as called from the mocha tests.
This is my launch.json:
{
"version": "0.1.0",
"configurations": [
{
"type": "node",
"request": "launch",
"protocol": "inspector",
"name": "Mocha All",
"windows":{
"runtimeExecutable": "c:\\Users\\alern\\AppData\\Roaming\\npm\\_mocha.cmd"
},
"args": [
"--colors",
"${workspaceFolder}\\test\\test.js"
],
"console": "integratedTerminal",
"internalConsoleOptions": "neverOpen"
}
]
}
when I press Run on my "Mocha All" configuration in VSCode,
global installation of mocha.cmd starts running, I see the following in the terminal:
cd 'd:\Projects\Algorithms\LinkedList'; & 'c:\Users\alern\AppData\Roaming\npm\_mocha.cmd' '--inspect-brk=30840' '--colors' 'D:\Projects\Algorithms\LinkedList\test\test.js'
(node:21524) ExperimentalWarning: The ESM module loader is experimental.
The above makes sense.
And then I see:
all of my tests simply rip through --- although I have setup some breakpoints in the Mocha scripts, they get ignored. So thats useless.
once all the tests are done (some successful, some not), at the end I get a popup that says:
"Cannot connect to runtime process, timeout after 10000ms - reason: Cannot connect to target: connect ECONNREFUSED 127.0.0.1:30840" This error feels like my process is done running and gone away, and VSCode or debugger are trying to connect to it?
In any case, what do I tweak to have my breakpoints stop execution? Thank you
The first thing I might try is to change the type to "pwa-node". I think mocha or VSCode recently made some changes that make that mandatory. You might also not want to set the runtime executable, but rather the "program". Generally the runtimeExecutable will be node, and if it's on your path VSCode should be able to find it automatically.
If all else fails I'd also try looking at the default configuration that ships with VSCode and see if that gives you any clues. That can be accessed by adding a new configuration through the "Add Configuration..." button. https://code.visualstudio.com/docs/nodejs/nodejs-debugging#_launch-configurations-for-common-scenarios
I am using Cypress for end to end testing, and I would like to be able to see all run test suites, in the browser, even after they are run. Currently, after each test suite is completed (test which are stored in separate files), the browser reloads and I cannot see previously run tests, and after the final test suite, the browser closes. Is there an option to change this behavior so that I can run all test files, have all the results visible in the browser and that the browser doesn't close at the end?
I am currently running tests using this command: ./node_modules/.bin/cypress run --headed --spec 'cypress/integration/tests/*'
where /tests is the folder where I currently have my files.
I have added --no-exit but in this case cypress doesn't move to the next test file and only the first one runs.
A workaround solution could be to generate reports with Mochawsome, for each Test Spec, and then merge and view those rendered reports. The reports will contain the results from the tests, test bodies, any errors that occurred and some other bits of information.
If you read through the page in the link it shows you how to generate individual reports then combine them together, and then render them as HTML. These can then be viewed in the browser.
This command can be used to install what's needed npm install --save-dev mochawesome mochawesome-merge mochawesome-report-generator
and then add the Reporter configuration to the cypress.json:
{
"reporter": "mochawesome",
"reporterOptions": {
"reportDir": "cypress/results",
"overwrite": false,
"html": false,
"json": true
}
}
Keep in mind that it may not give you the level of detail that is contained in the Cypress Dashboard in the browser, for example, what was yielded from a request.
Cypress has a lot of possible command with a lot of possible config too.
Read this.
And if you use npm just run like this :
npm run cypress:open
and in your package.json :
"scripts": {
"cypress:open": "cypress open"
}
I am using protractor with jasmine framework. I need solution to stop the execution of running the suite if previous suite fails.
I have three set of test suites as below:
1. Health check - Tests all the web services are returning 200 response.
2. Smoke test - Checks the basic features of front end are looking good.
3. Regression test - Tests all the features.
My requirement is, If health check test case fails then do not run smoke test cases.
This can be achieved through following two ways:
1. Jenkins
2. Using process.exit(1) in the script
But, these two are not fit to my need.
Is there any way to achieve my need through protractor or jasmine way?
You could achieve it using several scripts in package.json. For example:
...
"scripts": {
"health": "launch here only health",
"smoke": "launch here only smoke",
"regression": "launch here only regression",
"test": "npm run health && npm run smoke && npm run regression",
},
...
You will launch all tests using npm run test. If in some command appears error the others will not be execute.
I'm using Visual Studio Code.
I just created a resolvejs application.
How to run the application step by step from vscode ?
Here is my debugging setup (in .vscode\launch.json):
{
"type": "node",
"request": "launch",
"name": "Debug",
"program": "${workspaceFolder}/run.js",
"args": [
"dev"
],
"runtimeExecutable": "${workspaceFolder}/node_modules/.bin/babel-node",
"runtimeArgs": [
"--nolazy",
"--inspect"
]
}
My breakpoints in my command handlers do not work.
Although file run.js is some kind of entry point in resolve framework-based application, it is not actual entry point for runtime phase. When resolve application is being launched by yarn dev / npm run dev command, in fact two actions are performed: building bundle using run.js (which by default uses config.[MODE].js files for appropriate mode) and launching target bundle in separate process with watch mode, which causes automatic rebuild on every file change in project (aka hot reload).
Bundle is stored at <APP_DIR>/dist/common/local-entry/local-entry.js. To allow debugging from IDE, spawned debug nodejs should invoke target bundle directly. It can be reached by separating application compile- and runtime phases.
Resolve includes command for application building without run it - yarn build / npm run build. This command builds application in production mode, but this behavior can be easily modified to development mode by editing run.js entry point - just find line case 'build': and replace following line from await build(merge(baseConfig, prodConfig)) to await build(merge(baseConfig, devConfig)). Or additional script for building app in dev mode can be appended, like yarn build-dev - amount of possible scripts is unlimited.
Then just run command yarn build and start debugger with pointing entry point as ${workspaceFolder}/dist/common/local-entry/local-entry.js. If source maps had built right, breakpoints should work fine.