I'm new to cucumber for Cypress and I can't seem to get step definition files in my common folder to be used. My tests work if all of my steps are in the file which the feature file links to but if I put any of the steps in my "commonSteps.js" file that's inside my integration/common folder then the test fails saying that it can't find a step definition for the common step. What am I doing wrong?
I've tried adding the commonPath to the package.json and that doesn't work either.
nonGlobalStepDefinitions is also set to true.
Image of file structure
The problem must be in your cypress-cucumber-preprocessor in package.json, without seeing it's hard to say exactly what the problem is.
You can find here a guide to what different combinations of settings lead to. https://dev.to/jankaritech/e2e-testing-with-cypress-03-cypress-cucumber-gherkin-integration-350j
I think it should be
"cypress-cucumber-preprocessor": {
"nonGlobalStepDefinitions": true,
"commonPath": "integration/common",
"stepDefinitions": "integration"
}
Also, just a hint, if cypress runner is already running and you change something on the package.json, you need to restart the cypress runner to see what your changes result in, it's not enough to just restart a test case in the runner.
It seems that your folder structure is not defined properly in the config file. Here the steps you need to consider in order to run cypress-cucumber test successfully.
First, folder and file names should be same like common => common.js and same name for feature file too, such as common.feature.
Then you need to define the folder structure in the package.json file and also set your nonGlobalStepDefinitions to false.
"cypress-cucumber-preprocessor": {
"nonGlobalStepDefinitions": false,
"stepDefinitions": "cypress/integration/common"
},
Now, save and re-run your test. Hopefully this time it should work.
Related
I tried the new DataSpell today, but fail to create a project. Every time I try to attach a directory, it has been marked as a library. And it seems like the Project is always in
C:\Users\XXX\AppData\Roaming\JetBrains\DataSpell2021.3\projects\workspace
What's more, the intended project root folder (i.e., Test_2) is marked as a Module,
What's more, I can not mark the directory as well as all the subdrectories within it:
Does anyone know how to create a PyCharm like project in DataSpell?
I am trying to test my config files by validating them, nothing fancy, a schema, a list of envs, iterate over it, load the config and validate the variable against the schema.
Problem is, to do that, I currently have to set process.env.NODE_ENV. Since the tests have their own reserved config file, this mean if the tests were run in parrallel, it may happen that the test change the NODE_ENV variable when the other tests are loading the config, which while it doesn't seems likely to happens, still bother me.
A simple solution would be to be able to tell node-config to ignore the environment variable, and use a given value as if it was, something like require('config')('myNodeEnv'), but I couldn't find anything similar in the wiki nor the documentation. The closest is custom env variable, but this would just move the problem to another variable.
Instead of tests having their own config files, tests should load a same "base" test-config.
When a specific test needs to override a specific value it should override that specific value and not the entire config (needless to say, we need to make sure to fix the overridden value when the test finishes).
When we work as described above, it reduces the chances of any collision because the chances that different tests will override the exact same value at the exact same moment is very low.
Another option is to run tests separately, for example:
npm run test:suite1
npm run test:suite2
where test:suite1 could be declared in package.json under scripts section, for example:
"test:suite1": "NODE_ENV=test-conf-1 tests/suite1.js",
...
I've been following this Suave tutorial:
https://legacy.gitbook.com/book/theimowski/suave-music-store/details
And in general this looks good. However, I was trying to make it work with Linux and for some reason I was unable to compile it with code when TargetFramework was set to "net461" (Target Framework not found), so I tried changing it to "netcoreapp2.0". It compiled, but I hit a problem later on:
https://theimowski.gitbooks.io/suave-music-store/content/en/css.html
At the end it says to add a WebPart:
pathRegex "(.*)\.(css|png)" >=> Files.browseHome
which fails for me. All compiles, but I get
This page isn’t working
localhost didn’t send any data.
I took a look at Suave's source code and it turned out that "Files.browseHome" searches for a file under "ctx.runtime.homeDirectory".
I noticed that this is set on my machine to:
/home/<my_user_name>/.nuget/packages/suave/2.2.1/lib/netstandard1.6
and obviously, that's not my project directory, so no wonder it couldn't find the file.
My question here is: what shall I do in order to make my Suave app handle my css/png files correctly using Files.browseHome ?
EDIT:
Just found out that replacing the WebPart with:
pathRegex "(.*)\.(css|png)" >=> Files.browse "/home/<my_username>/<path_to_my_project>/bin/Debug/netcoreapp2.0/"
works fine, but it looks ugly. Any idea how to make it better ? Basically I don't want to be forced to hardcode the absolute path anywhere.
I think the answer is to be found in https://suave.io/files.html, which suggests creating a config as follows:
let config =
{ defaultConfig with homeFolder = Some (Path.GetFullPath "./public") }
The path returned by Path.GetFullPath will depend on the current working directory that your app sees when it's started (which will, in turn, depend on how you start the app: from the command line, from a systemd unit file, etc.) There are too many possible variables here for me to be able to give you exact instructions, but if your startup method can cd into an appropriate folder before starting your Suave server, then that should solve your problem.
If you run into difficulties with getting the current working directory set correctly, then you could just hardcode the full path in the config:
let config =
{ defaultConfig with homeFolder = Some "/home/<your_username>/<path_to_your_project>/bin/Debug/netcoreapp2.0/" }
But that's kind of ugly, and not really portable (you'd have to modify that path again once you deploy the app). So I'd recommend the approach of making sure your start script does a cd to the right location, then using Path.GetFullPath with a relative path. Alternately, you could have a config file that gets read in at app startup where you specify the home path, or pass it in as an environment variable... All kinds of possibilities. Just make sure that your code can be handed some information on startup that specifies the correct "home" folder, and then put that in your Suave config as I've shown, and that should solve it.
Sample situation
I have my own Yeoman generator, which has a folder with "template" of the resulting project.
The generator takes some information from user, interpolates the "template" with the information and then outputs a simple working project.
I want to ensure the "template" is actually working, at least in one positive scenario if not with all combination of inputs. I can write integration tests (which will run the generator with some data and then try to run the resulting code and verify whether all works as expected), but still, that's sometimes too much work and it's inconvenient for trial and error kind of development or some prototyping.
Question
Is there an easy way how to work with the "template" itself, how to run it or use it locally, manually, without the need to run the generator first every time I change a single letter in files of the "template"?
Maybe some sort of build step, which would run the generator for me with some preset data? Is there anything ready in form of npm module? Does a best practice exist?
After running the integration test, you can spawn some commands in the generated project folder and see if those are passing fine.
So far, the best solution I found is to create a script, which:
Creates a temporary sandbox directory.
Performs npm link
Alters the PATH so it does not contain .bin of your local node_modules (this is needed to prevent locally installed Yeoman take precedence over the global one when the script is ran e.g. as npm run develop).
Sets an environment value NON_INTERACTIVE to something truthy.
Runs yo <your generator> in the sandbox directory.
Runs npm start in the sandbox directory to run the freshly generated server code.
Change your generator so it is able to automatically provide some dummy default values for required prompts without default values if process.env.NON_INTERACTIVE is truthy.
Then run the script as:
$ nodemon --watch <directory with your template> --exec <path to your script> --ext js
It's slow, but it works. This way you can develop the template itself and avoid filling the generator every time you need to try out something.
I just though I make my life easier by sticking to common structures, so I started transferring a chrome browser extension to a yeoman template format
(https://github.com/yeoman/generator-chrome-extension).
Unfortunately it simply does not work when I try to just add my first basic bower source that I need:
https://github.com/Yaffle/EventSource
Here is what I did:
Set up the new extension with the yeoman helper
$ bower install EventSource --save
Added event source to the manifest like so
"background": {
"scripts": [
"scripts/chromereload.js",
"app/bower_components/EventSource/eventsource.js",
...
Add "new EventSource('http://localhost:9292/updates');" to background.js
Other than that the project is untouched.
And whenever I start the project with grunt it fails not finding EventSource like so "'EventSource' is not defined."
Adding the eventsource.js directly to my script folder and require it from there fails even worse by linting the eventsource.js file (that works perfectly fine) and aborting it for too many warnings (like using single quotes).
Previously this whole project worked pretty fine without grunt/bower and now it won't even start after I added the first real line of code. This is quite disappointing for a tool that is supposed to make your life so much easier.
Does it fail because of the warnings in the eventsource.js? In the first case (via bower) it does not say anything about this so I'm not sure.
I could go on trying out different combinations but I'm obviously missing a core concept or something like this here.
Any idea?
Update:
After some more trying and giving up i found the magic "grunt bowerInstall" command, to add the script-tags in the template automatically - still no help.
I did also try again on a fresh project with just jQuery (assuming this has to work..), well it still does not.
Neither in the popup.js (where the html template includes jQuery) nor in the background script (where the manifest includes it).
I probably read every manual/how-to on hot to use either of those components and still get nowhere.
Another day another try:
Starting with a clean mind i looked a bit more into it today finding out that apparently you have to "whitelist" globals like $ in jshint like so:
http://jshint.com/docs/options/#jquery
Still not sure if this is actually the best approach as it seems very counter-intuitive with promised ease of getting started of the yeoman/grunt/bower framework.
EventSource is probably a global variable. You can try declaring it as false in the .jshintrc file to prevent it from being overwritten.
"globals" : {
"chrome": true,
"crypto": true,
"EventSource": false
}
See if that works.
Read more about .jshintrc + global variables at: JSHint and jQuery: '$' is not defined