I'm trying to call some feature file with scenarios divided by #env tag. For example scenario with tag #env=dev and other scenario with tag #env=stage.
But when I'm calling it -- all scenarios are executing, for all envs. Is it any way to make it working, or I should try other realization of it?
The env is a "special" tag and for this to work, you need to set the karate.env on the command line: https://github.com/karatelabs/karate#environment-tags
Maybe you didn't set the Karate environment.
Related
Is the URL not available across feature files anymore?
As example, in our main feature files we would set the background as such:
Background:
* url url
* header Authorization = token
* def baseUrl = 'care/v1.1/account/'
Where the url is coming from our javascript config file. We have multiple environments we run our Karate suite on, and have config files that point to each of them, therefore the url is unique per environment. Then in the required scenarios there would be a call to a "helper" feature file. Inside that feature file there would be no background and only 1 scenario. That scenario would look like:
* path baseUrl
Given path 'MTYzODJAQDg=/call/add'
That would work fine with Karate 1.20. Now on Karate 1.3.0.RC2 that setup is failing. It's like the url variable is not being shared or something with the helper feature files. The scenarios that call helper feature files will now fail.
I've been able to "fix this", by adding the same url declaration that is in the main feature files, to our helper feature files, essentially so all feature files have it.
My question is, is this now the expected behaviour in the new version.
First, path is not a "variable" and it is NOT designed to work when you call anything.
I have 2 suggestions.
Set your environment-specific config in karate-config.js. That is what it is designed for, and you can very well call a feature to do it. See karate.callSingle().
Use variables to "pass around" information which "called" features can use. Or when you make a call, you can "return" values that can be used by subsequent steps.
I think that trying to use a "call" instead of pre-setting variables is the source of your troubles. If you need to switch the url when you call something, just use a variable.
Adding the url declaration (* url url) to the "helper" feature files, essentially having it in every feature file, will "fix" the "problem".
I have a jenkins job that makes an XML request and returns an answer. From this answer I have a string I need on nightwatch to start the tests.
Does anyone know how I can send this string to nightwatch? Maybe via a command line argument? But how to read it next?
Since you're using a NodeJS-based framework, why not make use of a process.env variable?
Suppose you need to tell your script what environment you want to run your checks agains. Let's call our system variable ENV. Your command will become:
ENV=prod nightwatch nightwatch.conf.js --yourOtherSwitches
In your page-objects/feature-files, you call the variable using process.env.ENV.
A header (Authorizathion) I set in the one scenario still exists when second scenario is ran.
I've looked through the documentation http://docs.behat.org/en/v3.0/ but I could find anything about my problem there.
Why is that ?
Use #insulated feature tag, this will start a clean browser for each scenario.
If this is not the issue use a method in #BeforeScenario hook where you can call reset/restart session methods.
This doesn't seem like a situation that is unique to me, but I haven't been able to find an answer anywhere.
I am attempting to build Jmeter scripts that can be executed both in the GUI and command line. The command line is going to need values to pass into the test cases, but the same test cases need to be executed via the GUI as well. I initially had separate scripts for GUI and command line, but it seemed redundant to have the same test cases duplicated with just a couple parameters changed.
For example, the GUI test case has the Web Server name set to:
<!-- ${ENV} set in User Defined Variables -->
<stringProp name="HTTPSampler.domain">${ENV}</stringProp>
The command line test case uses the following for parameters:
<!-- Define via command line w/ -JCMDDEV -->
<stringProp name="HTTPSampler.domain">${__P(CMDENV)}</stringProp>
Both work for their served purpose, but I want to combine the tests to be easier maintained and to have the ability to run them via GUI or command line.
I got passed one hurdle, which was combining the GUI Variables to be used as well as Properties for the command line by setting the User Defined Variable ${ENV} as the following:
Name Value
----- --------
ENV ${__P(ENV,dev.address.com)}
I am now able to run the same test case via GUI and command line (defining a new environment with -JENV)
I'm not sure if I'm overthinking this, but I want to be able to add a variable to the property default in order to avoid typos, etc while handing it off to others. I tried a few variations that didn't seem to work:
Name Value
----- --------
ENV ${__P(ENV,${__V(DEV)})}
DEV dev.address.com
This gave me the following Request:
POST http://DEV/servlet
Instead of:
POST http://dev.address.com/servlet
I also tried using:
${__P(ENV,${DEV})}
${__property(ENV,,${__V(DEV)})}
${__property(ENV,,${DEV})}
I was looking into Jmeter nested variables, but it didn't provide any working solutions.
So to my main question, am I able to use variables as the property defaults. If so, how would I achieve that?
I found a way around this. It's not exactly how I wanted it, but it could work for right now.
I really wanted to keep everything in one place where people had to make edits, but I was able to get the User Defined Variables to work by adding the ${__P(ENV,${DEV})} to the HTTP Request Defaults Web Server Name instead of pre-defining it as a variable.
Now there are two Config Elements that potentially need to be edited with GUI execution, but I think it should work out better in the long run.
Yes, seems the author is right - looks like nested variable can't be evaluated in JMeter from the same variables scope.
I've created a different "User Defined Variables" set, added there "defaultValue" - and after that this option works:
${__P(myProperty, ${defaultValue})}
I created a simple smoketest for a portal running java/tomcat/jahia (cms) fronted by cache servers and big ip. Cucumber + Webrat + Mechanize is a good fit for a simple smoketest of this setup. (and it has been very easy to get started).
Right now I have hardcoded into /features/support/paths.rb the following lines:
module NavigationHelpers
#PATH="http://production-environment"
#PATH="http://staging-environment"
#PATH="http://test-environment"
PATH="http://localhost:8080"
#
def path_to(page_name)
case page_name
when /the homepage/
"#{PATH}/"
when [...]
...
end
end
end
World(NavigationHelpers)
Right now I manually switch the comments when I want to test different environments. The issue here is I'd love to get rid of the constant PATH and put a default value inside one of the support files. And i also want to be able to feed cucumber with this environment variable from the command line like so:
cucumber ENV=staging
How do you cope with this issue? Any suggestions? Links to code that deals with this? Snippets?
You can pass environment variables to Cucumber like you have done with ENV. Each environment vriable will then be available in Ruby's ENV constant. More details in the Wiki
(I just added this page - the feature has been around since 0.3.90 but was only ever mentioned in the History.txt file).