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/
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 am currently trying to extract property values from my properties file, but am running into some problems. I can't test this in ML query console, because the properties file doesn't exist there. I am currently trying to grab the values of the file like this
let $port := #{#properties["ml.properties-name"]}
I've also looked at
xdmp:document-get-properties(
$uri as xs:string,
$property as xs:QName
however that is limited to .xml files I believe. Does anyone have a way/work-around of accessing these values? I can't seem to find one I've looked at some documentation on Marklogic's website, but can't seem to get anything to work. The way I was accessing before was in ruby, through monkey-patching allowing me to access those private fields.The problem with that is the ruby script I call is only called once, while my .xqy file is ran every minute that sends args to another function. I need to access those args from the properties file, right now I just have them hard-coded in. Any thoughts?
Thanks
You cannot access deployment properties like that, but you can pass them along with deployment. If you create a new REST app with latest Roxy, you should get a copy of this config.xqy added to src/config/:
https://github.com/marklogic-community/roxy/blob/master/deploy/sample/custom-config.xqy
That file is treated specially when deployed to the modules database. Properties references are replaced inside there. In your case, add another variable, and give it a string value following the #ml.xyz pattern:
declare variable $c:port := "#ml.property-name";
You can then import the config lib, and use it in your code.
These so-called Deployer Substitutions are described in more detail on the Roxy wiki:
https://github.com/marklogic-community/roxy/wiki/Deployer-Substitutions
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.
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'm creating a unittest- and Selenium-based test suite for a web application. It is reachable by several hostnames, e.g. implying different languages; but of course I want to be able to test e.g. my development instances as well without changing the code (and without fiddling with the hosts file which doesn't work for me anymore, because of network security considerations, I suppose).
Thus, I'd like to be able to specify the hostname by commandline arguments.
The test runner does argument parsing itself, e.g. for chosing the tests to execute.
What is the recommended method to handle this situation?
The solution I came up with finally is:
Have a module for the tests which fixes the global data, including the hostname, and provides my TestCase class (I added an assertLoadsOk method to simply check for the HTTP status code).
This module does commandline processing as well:
It checks for its own options
and removes them from the argument vector (sys.argv).
When finding an "unknown" option, stop processing the options, and leave the rest to the testrunner.
The commandline processing happens on import, before initializing my TestCase class.
It works well for me ...