Is there a way to pass custom arguments to the RFT automation script through command line ?
I was trying to launch my driver script for automation(scripted in RFT 8.0.6) through command line and I was able to do so successfully. I wanted to pass the row number(iterator)- from where my test datapool should be read, as an argument to my driver script through command line. Is it a possibility to do so from commandline?
Any help is much appreciated.
java.exe -jar rational_ft.jar -datastore <project_path> -playback <scriptName> -args one two three
The script will get
three arguments i.e one two and three
Related
I'm using gcov and I'd like to gather coverage results on a per test case basis.
QUESTION
When I execute the googletest executable, is it possible to pass in an argument on command line that says execute only the Nth test case?
I'd even be ok with passing in the name of the fixture+case; I can just use Python with regex to pull out all the tests.
Obviously I can accomplish the same thing by having one test case per .cpp file but that sounds ... stupid.
googletest allows to run a single test case or even the subset of the tests. You can specify a filter string in the GTEST_FILTER environment variable or in the --gtest_filter command line option and googletest will only run the tests whose full names (in the form of TestSuiteName.TestName) match the filter. More information about the format of the filter string can be found in Running a Subset of the Tests section. Also googletest supports --gtest_list_tests command line option to print the list of all test cases. It can be useful in your case.
I'm asking for help on how to run a feature file scenario just by name. I've been trying for a while and it does not come out. I know that can be done by tags or by line number, but I wonder if we can run a cucumber test by name, more or less with this nomenclature.
Given a file named "features/test.feature" with:
Feature:
Scenario: My first scenario
Given this step is blah blah blah
Scenario: My second scenario
Given this step too blah blah
I want to run a scenario by name from the console or with gradle, maybe similar this way
cucumber features/test.feuture::My second scenario
Or maybe with gradle
./gradlew cucumber::My second scenario
You didn't describe how you start cucumber so I can't help you with that.
When used from the CLI accepts --name REGEXP. This will only run scenarios whose names match REGEXP.
The #CucumberOptions annotation accepts name="REGEXP".
Cucumber < v6.0.0 looks at the environment. For maven you can add -Dcucumber.options=--name REGEXP. I don't know the equivalent for gradle. Take note that the escape characters maybe shell/build system dependent.
Cucumber v6.0.0 and above looks at the environment. For maven you can add -Dcucumber.filter.name="REGEXP".
See:
https://cucumber.io/docs/reference/jvm#running
https://github.com/cucumber/cucumber-jvm/tree/main/core
From cucumber 6.x, you can run a scenario with below CLI commands:
// Specify a scenario by its line number
$ cucumber-js features/my_feature.feature:3
// Specify a scenario by its name matching a regular expression
$ cucumber-js --name "topic 1"
But, these are time-consuming and repetitive. You can save a lot of time by using a dedicated VSCode Extension called Cucumber-Quick. This extension will allow you to run a scenario/feature just by right-clicking on them. It can save you from all the hustle.
You would call the scenario by its line number.
So assuming that the second scenario starts on line 5 in your feature file you could run:
cucumber features/test.feature:5
I have a probelm to use an output from a test case to use it with another test tase like input value ! did you have an idea how to do that ?
Even I have seen this issue with Ride. Sometimes ride does not save changes. Need to restart ride to see the saved changes. So, I am using ride only for development purpose and using command line to run test cases. On one window edit changes in ride and run test cases on command line.
To run single test case from command line:
python -m robot -t test_case_name test_suite_name
Hope it clears your doubt.
I have the script in AutoIT (to handle upload file window in selenium)
WinWaitActive("File Upload")
Send("C:\Users\XXX\Desktop\Folder1\MyFile.xlsx")
Send("{ENTER}")
Instead of hard-coding pathname, I want to pick-up pathname from a property file.(So that tomorrow we dont to touch AutoIT script to modify pathname).
Is there any way to do so?
Update 1:
java code:
Runtime.getRuntime().exec(TestUtility.properties.getProperty("test.all.autoit.testdata"));
Thread.sleep(8000);
AutoIT code:
WinWaitActive("File Upload")
Send($CmdLine[1])
Send("{ENTER}")
Cmd line:
c:>java -jar pathToJar.jar pathToProperties.properties pathToFileUpload.xlsx
Properties file:
test.all.autoit.testdata='C:\\XX\\XX\\XX\\someFolder\\ListUploadScript.exe'
What I've done is AutoIt script can accept command line parameter for invoking so my Java test use to read that property from properties file and then when I invoke AutoIt script I invoke it with the property as command line option to the AutoIt script and accept that command line argument in AutoIt script as the path to the file to be uploaded. Let me know if this works for you!!!
Also if your upload button is of type input then no need use AutoIt..directly element.sendKeys(<Path to upload file>) should work
Sample Code:
WinActivate("File Upload")
WinWaitActive("File Upload")
Send($CmdLine[1])
Send("{Enter}")
Here $CmdLine[1] accepts the first command line argument passed. so while calling this script (.exe) call it in this way.
Runtime.getRuntime().exec("src/test/resources/fileupload.exe "+path);
where path is the path to the file which you wish to upload.
I assume you would already know when to call your AutoIt script :D
EDIT1 : $CmdLine[0] is reserved to get count of number of command line arguments passed to autoit script..so the actual arguments start with $CmdLine[1] which is the first argument passed on command line.
EDIT2: I am assuming you are running from a main method, if so then your call to execute autoIt script should be like this: Runtime.getRuntime().exec(TestUtility.properties.getProperty("test.all.autoit.testdata")+" "+args[0]);
where args[0] is the args array passed as argument to main method whose 0th Index has excel sheet which you wish to pass. Also you need to pass absolute path of the excel spreadsheet.
You can use ini files with IniRead and IniWrite functions
The file look like :
[SectionName]
KeyName1=Value
KeyName2=Value
And you read in the file with :
IniRead('nom_fichier.ini', 'SectionName', 'KeyName1', 'Default Value')
It seems as if a script with #! prefix can have the interpreter name and ONLY one argument. Thus:
#!/bin/ls -l
works, but
#!/usr/bin/env ls -l
doesn't
Do you agree? Any thoughts?
Francesc
Different Unixes interpret #! differently. Here's a comprehensive-looking writeup: http://www.in-ulm.de/~mascheck/various/shebang/
It seems that the lowest common denominator across platforms is "the interpreter (which must not itself be a script) and no more than one argument".
Originally, we only had one shell on Unix. When you asked to run a command, the shell would attempt to invoke one of the exec() system calls on it. It the command was an executable, the exec would succeed and the command would run. If the exec() failed, the shell would not give up, instead it would try to interpret the command file as if it were a shell script.
Then unix got more shells and the situation became confused. Most folks would write scripts in one shell and type commands in another. And each shell had differing rules for feeding scripts to an interpreter.
This is when the “#! /” trick was invented. The idea was to let the kernel’s exec () system calls succeed with shell scripts. When the kernel tries to exec () a file, it looks at the first 4 bytes which represent an integer called a magic number. This tells the kernel if it should try to run the file or not. So “#! /” was added to magic numbers that the kernel knows and it was extended to actually be able to run shell scripts by itself. But some people could not type “#! /”, they kept leaving the space out. So the kernel was expended a bit again to allow “#!/” to work as a special 3 byte magic number.