Versions
Cypress version: 8.4.0
Preprocessor version: 4.2.0
Node version: 12.18.2
Hi all, apologies if this is a stupid question, I'm quite new/noob with cypress, let alone cypress + cucumber.
So I wrote some automation tests in cucumber, and they work fine. I have the feature files in the integration folder, and the step definition folders in the integration folder too. Now I'm trying to have some structure where under integration I have a folder named step_definitions (will show better in screenshot).
folder structure
In package.json I put the following:
"cypress-cucumber-preprocessor": { "nonGlobalStepDefinitions": true, "nonGlobalStepBaseDir": "step_definitions", "commonPath": "common", "stepDefinitions": "step_definitions" }
When I try to run the tests, I get the below error:
Error: We've tried to resolve your step definitions at step_definitions, but that doesn't seem to exist. As of version 2.0.0 it's required to set step_definitions in your cypress-cucumber-preprocessor configuration. Look for nonGlobalStepDefinitions and add stepDefinitions right next to it. It should match your cypress configuration has set for integrationFolder. We no longer rely on getting information from that file as it was unreliable and problematic across Linux/MacOS/Windows especially since the config file could have been passed as an argument to cypress.
Any pointers are appreciated :)
It seems to me that the problem in your case in "stepDefinitions": "step_definitions" have you tried to give the full path like "stepDefinitions": "cypress/integration/step_definitions"?
You should set nonGlobalStepDefinitions to false or remove this setting, as you don't have a separate folder for the step_definitions but it is inside the integration folder instead.
So, in order to use your structure, please modify that section in the package.json file to:
"cypress-cucumber-preprocessor": {
"commonPath": "cypress/integration/step_definitions/common",
"stepDefinitions": "cypress/integration/step_definitions"
}
That would be enough. It works.
Related
Facebook's Pysa tool looks useful, in the Pysa tutorial exercises they refer to files that are provided in the pyre-check repository using a relative path to include a path outside of the exercise directory.
https://github.com/facebook/pyre-check/blob/master/pysa_tutorial/exercise1/.pyre_configuration
{
"source_directories": ["."],
"taint_models_path": ["."],
"search_path": [
"../../stubs/"
],
"exclude": [
".*/integration_test/.*"
]
}
There are stubs provided for Django in the pyre-check repository which if I know the path where pyre check is installed I can hard-code in my .pyre_configuration and get something working but another developer may install pyre-check differently.
Is there a better way to refer to these provided stubs or should I copy them to the repository I'm working on?
Many projects have a standard development environment, allowing for hard coded paths in the .pyre_configuration file. These will usually point into the venv, or some other standard install location for dependencies.
For projects without a standard development environment, you could trying incorporating pyre init into your setup scripts. pyre init will setup a fresh .pyre_configuration file with paths that correspond to the current install of pyre. For additional configuration you want to add on top of the generated .pyre_configuration file (such as a pointer to local taint models), you can hand write a .pyre_configuration.local, which will act as an overlay and overwrite/add to the content of .pyre_configuration.
Pyre-check looks for the stubs in the directory specified by the typeshed directive in the configuration file.
The easiest way is to move stubs provided for Django in the pyre-check repository to the typeshed directory that is in the pyre-check directory.
For example, if you have installed pyre-check to the ~/.local/lib directory, move the django directory from ~/.local/lib/pyre_check/stubs to ~/.local/lib/pyre_check/typeshed/third_party/2and3/ and make sure your .pyre_configuration file will look like this:
{
"source_directories": ["~/myproject"],
"taint_models_path": "~/myproject/taint",
"typeshed": "~/.local/lib/pyre_check/typeshed"
}
In this case, your Django stubs directory will be ~/.local/lib/pyre_check/typeshed/third_parth/2and3/django
Pyre-check uses the following algorithm to traverse across the typeshed directory:
If it contains the third_party subdirectory, it uses a legacy method: enters just the two subdirectories: stdlib and third_party and there looks for any subdirectory except those with names starting with 2 but not 2and3, and looks for the modules in those subdirectories like 2and3, e.g. in third_party/2and3/
Otherwise, it enters the subdirectories stubs and stdlib, and looks for modules there, e.g. in stubs/, but not in stubs/2and3/.
That's why specifying multiple paths may be perplexing and confusing, and the easiest way is to setup the typeshed directory to ~/.local/lib/pyre_check/typeshed/ and move django to third_parth/2and3, so it will be ~/.local/lib/pyre_check/typeshed/third_parth/2and3/django.
Also don't forget to copy the .pysa files that you need to the taint_models_path directory. Don't set it up to the directory of the Pyre-check, create your own new directory and copy only those files that are relevant to you.
I have this matchers file which I would like to include in karma:
link: https://github.com/froots/jasmine-sinon
I'm using jasmine and sinon. I don't think this plugin is supported by karma. Can I manually configure it somehow?
I tried to add it in config files but karma didn't pick it
files: [
'bower_components/jasmine-sinon.js' //Added it here ???
'bower_components/jquery/dist/jquery.js',
'bower_components/underscore/underscore.js',
'bower_components/backbone/backbone.js',
'app/js/*.js'
],
https://www.npmjs.com/package/karma
you will need to have it point directly to the file, in this case, the correct path should be bower_components/jasmine-sinon/lib/jasmine-sinon.js.
Can a Ruby test get the location of the folder where Rake executed it from? I want to run Test::Unit unit tests using Rake but my defined "test suites" in Rake need to be able to find locations of libraries relative to the root of my project.
With Maven, I can set a system property like so :
<properties>
<main.basedir>${project.basedir}</main.basedir>
</properties>
And then Java can reference it like so:
String baseDir = System.getProperty("main.basedir");
Can Ruby do something similar? If so, how? Do I need to use a Rake namespace-require + include ? Not brewing my own framework: just trying to do the most basic test setup. I do have some lib files I created that my tests want to use.
This doesn't work because it hard codes the base dir into the class file:
base_dir = File.expand_path(File.join(File.dirname(__FILE__), ".."))
You can probably do this by injecting it in a test helper and getting the base location relative to the location of the file the test helper is is, but I would like to ask you what are you actually trying to achive?
normally the tests have access to the lib path and you should be able to just require what you want to use in the tests directly. are you using something like rspec or test::unit? are you brewing your own test framework?
so overall the answer is yes you can do it, but you should not have to do it. can show you how once you clarify what test framework you're using.
Edit
For test unit, this describes almost what you want to do:
https://github.com/test-unit/test-unit/blob/master/doc/text/how-to.md
The run_test.rb helper is placed in test. You see how the base dir is built by using the path of file (as mentioned above) and how the lib dir is placed on the load path.
Is there a way to link with a library that's not in the current package path.
This link suggests placing everything under the local directory. Our packages are installed in some repository elsewhere. I just want to specify the libpath to it on windows.
authors = ["Me"]
links = "CDbax"
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
But trying cargo build -v gives me
package `hello v0.1.0 (file:///H:/Users/Mushfaque.Cradle/Documents/Rustc/hello)` specifies that it links to `CDbax` but does not have a custom build script
From the cargo build script support guide, it seems to suggest that this should work. But I can see that it hasn't added the path. Moving the lib into the local bin\x68_64-pc-windows-gnu\ path works however.
Update
Thanks to the answer below, I thought I'd update this to give the final results of what worked on my machine so others find it useful.
In the Cargo.toml add
links = "CDbax"
build = "build.rs"
Even though there is no build.rs file, it seems to require it (?) otherwise complains with
package `xxx v0.1.0` specifies that it links to `CDbax` but does not have a custom build script
Followed by Vaelden answer's create a 'config' file in .cargo
If this is a sub crate, you don't need to put the links= tag in the parent crate, even though it's a dll; even with a 'cargo run'. I assume it adds the dll path to the execution environment
I think the issue is that you are mistaking the manifest of your project with the cargo
configuration.
The manifest is the Cargo.toml file at the root of your project. It describes your project itself.
The cargo configuration describes particular settings for cargo, and allow for example to override dependencies, or in your case override build scripts. The cargo configuration files have a hierarchical structure:
Cargo allows to have local configuration for a particular project or
global configuration (like git). Cargo also extends this ability to a
hierarchical strategy. If, for example, cargo were invoked in
/home/foo/bar/baz, then the following configuration files would be
probed for:
/home/foo/bar/baz/.cargo/config
/home/foo/bar/.cargo/config
/home/foo/.cargo/config
/home/.cargo/config
/.cargo/config
With this structure you can specify local configuration per-project,
and even possibly check it into version control. You can also specify
personal default with a configuration file in your home directory.
So if you move the relevant part:
[target.x86_64-pc-windows-gnu.CDbax]
rustc-link-lib = ["CDbax"]
rustc-link-search = ["Z:/Somepath//CPP/CDbax/x64/Debug/"]
root = "Z:/Somepath//CPP/CDbax/x64/Debug/"
to any correct location for a cargo configuration file, it should work.
I'm having trouble getting the lobos database migrations library for Clojure to play with the maven-clojure-plugin and Maven-style project structure. Lobos looks for database migrations in the lobos.migrations namespace. If I layout the project Leiningen style:
src/
lobos/
migrations.clj
lobos correctly finds lobos.migrations at run time, when run via lein. However, if I lay out the project Maven-style:
src/
main/
clojure/
lobos/
migrations.clj
and use the maven-clojure-plugin to run the same tests, lobos no longer finds lobos.migrations. I thought this was an issue with the clojure-maven-plugin, but I have the same issue (lobos not finding lobos.migrations) if I run via leon, setting the source paths in project.clj appropriately:
:source-paths ["src/main/clojure"]
If I move lobos/ back under src/ and add src/ as a source path:
:source-paths ["src" "src/main/clojure"]
then lobos correctly finds lobos.migrations again.
I would like to use a Maven-style project layout (and eventually the maven-clojure-plugin). How can I help lobos find lobos.migrations? Where have I gone wrong?
The lobos.migration/*src-directory* variable indicates the source root for finding source for the *migrations-namespace*. If lobos.migration/*reload-migrations* is true (the default), then lobos.migrations looks for the migrations namespace in this source directory. The default is src/, so it needs to be rebound to src/main/clojure in order to use a Maven-style directory structure.
One other notable issue: when running from a JAR (i.e. not from source), you must disable reloading of the migrations namespace as well:
(binding [lobos.migration/*reload-migrations* false]
;; run migration
)
You need to change the dynamic variable lobos.migration/*migrations-namespace*. This is documented here: https://github.com/budu/lobos#migrations.