I am trying to use script aliases in the package.json file.
In order for something like this to open the test runner,
"cy:open:prod": "cypress open --env ENV=production",
I run the command npm run cy:open:prod in the command line in the same folder that package.json is located.
The script runs and opens the test runner, however no spec files are found.
In all the examples I have found it describes this approach. Is there something I am missing in configuation to point it to where my spec files are?
Thanks in advance.
There is nothing basically wrong with the scripts in package.json, they look normal and would not cause the problem you mention.
I suggest you check the specPattern setting in configuration, it should match the naming convention you have chosen to use for your specs.
See e2e settings for more details.
Of you still have trouble with it, start a new project and let Cypress set the configuration for you, it will automatically match up the specPattern to the default value.
Related
I am storing my cucumber html report under cucumber-html-reports folder and json files are storing under cucumber-json folder. Now I want delete/empty these two folders. I need a plug in to achieve this.
The correct way to do this is to add an npm script to clean up the report folder and execute it before the test run. Cypress has an example npm script on their website for this. https://docs.cypress.io/guides/tooling/reporters#Command-line-3
Usually, the CI/CD pipeline would run the clean up script before the test run kicks off. Alternatively, you could add a little bit of code to your plugins file to exec the npm script before the test run as well.
One sort of hacky option, there is a trashAssetsBeforeRuns option in the Cypress config (set to true by default). It's used to clean up the downloads, videos, and screenshots folders before a test run. If you map your reporter results to one of these directories that might work, although I can't guarantee success with it since I haven't done that.
I was looking something like this:
Here is my file structures
The logic used for determining what test runner is available for a given test file is based on dependencies declarations in package.json. Declaring "mocha" as a dependency in <project root>/package.json should enable mocha runner in <project root>/**/* files.
Note that if Mocha is not installed locally/included in package.json, you can create a Mocha run configuration with All in directory selected and specify a directory where your spec files are located. In this case, right-click on a test file inside this directory will suggest to run with Mocha.
The problem is caused by missing mocha in my npm dependencies. Maybe there is a way to tell Webstorm to look for the globally installed mocha.
Along the lines of this answer (which works for me, BTW) and the javadocs, I tried
gradle.startParameter.consoleOutput = org.gradle.api.logging.configuration.ConsoleOutput.Rich
in my ~/.gradle/init.gradle. However, I still need --console=rich to get color output. Why?
Tested with Gradle 2.14.1 and 3.2.1.
Terminal is cygwin urxvt with TERM variable set to rxvt-unicode-256color.
Since Gradle 4.3 you can use org.gradle.console property in gradle.properties:
org.gradle.console=rich
A new console verbose mode will print outcomes of all tasks (like UP-TO-DATE) like Gradle 3.5 and earlier did. You can set this via --console=verbose or by a new Gradle property org.gradle.console=(plain rich verbose).
I am not sure if you can force the rich console from a gradle script, as the detection happens likely before the script is interpreted.
NativeServices class provides the integration with the console. If you look at the source code, there are two messages possibly printed in log:
Native-platform terminal integration is not available. Continuing with fallback.
Unable to load from native-platform backed ConsoleDetector. Continuing with fallback.
The latter might give you more information why. Try running the gradle script with --debug. You will likely find out that you are missing a native library that is either not available in cygwin or it is, but is not on library path.
I believe it works when you specify the rich console from the command line, because gradle forces the colours even though the console doesn't indicate it supports them.
Does it work if you don't use the cygwin console in Windows native command line or maybe GitBash?
There is a workaround how you can make this work. You can create an alias in cygwin that will always add the --console=rich.
If you are using gradle wrapper, you can edit the gradlew script and add the command line parameter. To make it automated, you can change the wrapper task to alter your script in the doLast part.
Create a file called gradle.properties inside your ~/.gradle/ folder.
Inside gradle.properties, add the line org.gradle.console=rich.
Each builds will run under --console=rich automatically because the new gradle.properties will be merged with the gradle.properties of your project.
If your project's gradle.properties contains the same tag as the local file, your project's will be used overriding the local file's
If you are on Linux/Mac set
alias gradle='gradle --console rich'
in your ~/.bashrc.
In Gradle Wrapper, add the following line:
org.gradle.console=rich
to ./gradle.properties in the root folder, where the gradlew script is located.
I've configured and am executing mocha tests in WebStorm, so I know the module is working properly. But I can't seem to make it run from a Bamboo task. The task runs with Success but there are 0 tests executed.
This is my configuration atm:
app/ is my working dir. Tried also with app/node_modules/mocha/bin/ and other possibilities. I am not sure which exactly is the Mocha executable of all the mocha named files in the module...
Or maybe the problem lies in the tests dir? I've got test files, respectively in app/test/unit/models/ and app/test/unit/services/. But in WebStorm I configured it with the general test dir - just /app/test. Configuring the Mocha task in Bamboo with the specific test folders did not yield result...
I believe the problem comes from wrong directory configurations in the task, but I've tried writing whatever paths already and I've got no idea what's missing or wrong...
I noticed from your screenshot that the "Parse test results produced by this task" box isn't checked. This is what tells Bamboo to parse the output of the tests that you run.
I want to use oclint (an Objective-C static analyzer) for my projects but the official documentation does not clearly describe how to configure it.
How do I use it?
I have installed the oclint package then copied the script for capturing projects configs into a project's folder. Running this script creates an empty file named compile_commands.json and it does not fill xcodebuild.log with any data.
Thank you!
I don't think this script will add anything into xcodebuild.log. It reads from it. You may want to manually run xcodebuild and save the output into xcodebuild.log before running the script.
Check out the documentation.
I have had luck with the manual route of copying the script into my project's folder then executing it on the command line.
Though this does not integrate oclint's functionality into XCode, it does provide feedback via stdout.
From this feedback I then update my code to align with oclint's recommendation and iteratively run oclint until my code complies with oclint's rules.