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".
Related
i have an app that can show many popups in various scenarios, and i would like to verify their text using XCUITest. but would like to be able to do that with no effort for multiple text configurations. for multiple languages for instance.
Is there a way to pass arguments through the .xctestrun file or through the "xcodebuild test-without-building" command? some way to pass the dictionary, or a file that i can parse at the beginning of the XCTestCase to know the correct text values to predict? preferably without the need to rebuild the project.
Found the answer.
The test host (and your XCTestCases) can view its arguments same as the test target, using NSProcessInfo.processInfo.environment and NSProcessInfo.processInfo.arguments.
Using the scheme for "Test" in XCode, you can add arguments and environment variables that the test host itself can read. The test host can read these by using the process info as mentioned above.
Another way to do this would be by editing the xctestrun file for your test. In it, you can add the key CommandLineArguments as an array of strings for the process info arguments, or add EnvironmentVariables as a dictionary from key to string value.
An easy way to go about adding the arguments/variables to the xctestrun file manually would be to first add them to the Test scheme in XCode, see the changes to the xctestrun file, and modify them accordingly.
other xctestrun variables are described in https://www.manpagez.com/man/5/xcodebuild.xctestrun/
I am working on API testing project and have incorporated Karate to do so. Now my requirement is to create a server which will respond to the endpoint.All this is done but my requirement is to access variables defined in karate-config file in Server feature. I am unable to do so.
For example:
Feature: Sample server
Scenario: pathMatches('\variablevalue) ** methodIs('get')
def response = default_env
Note: default_env is a variable in karate-config.js file and holds some default value.
Great question, we deliberately did not want to mix the karate-config.js concept with the Karate server-side.
Normally when you instantiate a mock server via the API you can pass a Java Map and all key-values will end up as Karate variables.
But here's a trick, you can do this in the Background
* call read('classpath:karate-config.js')
And this will have the exact same effect you are looking for ! Do let me know if this works, I will make sure this is updated in the documentation.
Note that you can use JSON if all you need is some seed-data:
* def cats = read('cats.json')
I am attempting to build a little modification in our code to allow easier A/B testing.
I'd like to know if I can somehow
have my regular code under the /templates directory
have any a/b code under /templates/_abtests/, but also follow the same hierarchy as the regular code. for example... an ab test can overwrite a file like '/templates/foo.tpl', and use instead '/templates/_abtests/testfoo/foo.tpl'
I tried changing the template directory when in a test. Right before calling the display method, I would check if a user is in a test, and if so, set up the template_dir accordingly. I'd assign an array with the 'ab' directory first, then the default. I am using Smarty2.
the problem with this is that it caches the first instance, and uses that as the template for the baseline and ab test case. ie: i have a parameter to force me into a test bucket, but the template is the same.
thoughts on how to achieve this? goal is to not have to add a bunch of template hooks (if/else) in the templates. and achieve this by simple template/file includes.
I believe that the solution to my problem could be to put templates into folders. ie: /templates/base/, /templates/test_foo/, etc.". then in my template_dir setting, set the array up based on what test we are in.
I had tried this with mobile/desktop before, and forgot about this solution.
I can extend the smarty_template class and override the display method to change the template_dir. adding the test directory first.
I'm writing functional test and having difficulty mocking http:request-config with oauth2. It failed at requesting for token. I tried moving the config to a separate file and create a different config in src/test/resources and include only the test config when testing. Now it complains about "name must be unique" - how do I get around this?
Be sure that your getConfigFiles() override does not include the configuration file that contains the original . This means it will need to be in a separate file from the one containing the flow you are testing.
Another method is to use a mock HTTP server such as sham-http.
In order to test Mule application you can use MUnit:
http://developer.mulesoft.com/docs/display/current/MUnit
It will allow you to mock message processors.
Now, config elements are top level elements. Those can not be mock.
I would suggest you take a look to documentation to see if the tool fit your needs.
HTH
I have created a multi-layer build using build.dojotoolkit.org (my first attempt) with 3 layers: dojo.js, dojox.js, dijit.js. Each js file is uploaded in its own folder (dojo,dojox,dijit).
When I run the code, I would expect it to look in dijit.js to get the form modules like dijit.form.TextBox. But instead it tries to load dijit/form/TextBox.js and of course ends up with a 404 error.
What am I doing wrong?
The files are here if it helps:
http://usermanagedsolutions.com/Demos/Pages
Manually include each layer in a script tag on the page.
<script src="path/to/dojo.js" />
<script src="path/to/dojox.js" />
<script src="path/to/dijit.js" />
This will make available all modules that you have defined in the build. When you require the text box, Dojo will see that it has the code and will not make the XHR call.
Even though you do not have the intention of using the individual files, you may want to put them on the server as well. This way if someone forgets to add the file to the build, the penalty incurred is an xhr request, as opposed to a javascript error.
Re: AMD
When you include your layers in the manner that I described above, you are not loading all the modules that you included the build - you are just making the define functions available without having to make xhr requests.
If you look at the js file that is output from the build, the file contains a map of the module path to a function that when called will define the module.
So when you write the following code
require(["dijit/form/TextBox"], function(TextBox){
...
});
AMD will first determine if dijit/form/TextBox has already been defined. If so it will just take the object and execute the callback.
If the module hasn't already been defined, then AMD will look in it's cache to see if the define code is available. When you include your script files, you are providing a cache of define functions. AMD finds the code to define the module. It calls this define function and the result is the object that is passed into the callback. Subsequent requires for dijit/form/TextBox will also use this object as described above.
If the module hasn't already been defined and AMD does not find the define function in its cache, then AMD will make an XHR request back to the server to try to locate the specific module code. The result of the XHR call should provide the define function. AMD will call the function and use the result as the object to pass into the callback. Again, subsequent requires for dijit/form/TextBox will also use this object.
The Dojo build, provides the ability to 1) minify the code and 2) combine it into fewer files that need to be requested from the server.
AMD allows you to write code that can run in either environment (using built files or the individual files) without having to make modifications.