May be my question is unique but need to sorted out. We've a bunch of test cases and distributed across different folders Functional_TestSuite_XX. If I execute the batch file all Functional Suites will be executed at a time but only once. And we are using build.xml with some Ant commands to run this functionality. But, I need to execute same batch file for 'N' times depends on some condition (Number of folder available in some other folder). Any clue or suggestion can be appreciated. Thankyou!
Batch File Contains: python -m robot --variable <Some var 1> --variable <Some var 2> --variable <Some var 3> --outputdir .\output --argumentFile .\deploy\TestArgumentFile.arg Robot_TestSuites\Functional_TestSuite
Related
Is there a straightforward way when using ctest to get the number of tests passed (and/or failed) within a script, e.g., BASH, without grep-ping through a generated output file?
a straightforward way ... without grep-ping
No, I believe there is not.
You can also "grep" the count the lines Test failed. and Test passed. from CMake the_build_dir/Testing/Temporary/LastTest.log.
You could potentially generate ctest XML report to a dashboard and then parse the XML reports (instead of sending them). It's nowhere as straightforward, as ctest script has to be written that configures, builds and tests the project and then separate XML tool needs to parse the result.
You can also run a cdash server and let that ctest script upload the results to cdash and then query cdash server with simple curl 'https://your.cdash.server/api/v1/index.php?project=TheProjectName' | jq '.buildgroups[] | select(.id == 2).builds[] | { "pass": .test.pass, "fail": .test.fail, }. The querying is simple, but.. it needs to run a cdash server and also test with ctest script, it's not near straightforward..
Btw, it's easy to get the number of failed tests - it's just wc -l the_build_dir/Testing/Temporary/LastTestsFailed.log.
I am very new to creating batch files.
I have to run a command, with an increasing file number e.g
c:>program.bat -propertyfile "1.property"
Right now, I have to type the command manually, wait 1 minute, then type the command again by increasing the property file # i.e "2.property" "3.property" "4.property" etc....
I want to automate this, and still would like to see the results in the command prompt as it runs.
How can this be accomplished?
See https://ss64.com/nt/for.html and specifically https://ss64.com/nt/for_l.html
FOR /L %%G IN (1,1,4) DO program.bat -propertyfile "%%G.property"
Should run your command for files 1.property to 4.property but if you're actually running it for files in a directory rather than a list of integers one of the other FOR constructs might be more appropriate. Perhaps https://ss64.com/nt/for_r.html
I have my tests set up in the following structure using Robotframework:
Directory1:
- SuiteA
- SuiteB
- SuiteC
Directory2:
- SuiteA
- SuiteB
I want to execute all of the test suites from Directory1 first before executing the suites in Directory2 using "pabot". The test suites from Directory2 are dependent on test suites from Directory1 so the execution must be in this order. How can I order the execution this way?
I was reading online about using an argument file to specify the order of execution but I was not able to figure that out. I also read the documentation from Robotframework and named my test suites accordingly with the "number__testsuitename" naming convention but that did not work either.
Any ideas? Thanks in advance!
Basically, you need to modify the .pabotsuitenames file with the tests/suites that you want to run in parallel and also add the #WAIT flag in case that you need to run something sequentially, for example:
datasources:7a60d412cbd2efd728502cddce7ce4cd4b57aa42
commandlineoptions:65f95c924ba97541f47949701c4e3c51192a5b43
suitesfrom:no-suites-from-option
file:984cbf6a94ce4d05453079d2eedf2399a3cae664
--suite Directory 1 Name.Suite A Name
--suite Directory 1 Name.Suite B Name
--suite Directory 1 Name.Suite C Name
#WAIT
--suite Directory 2 Name.Suite A Name
--suite Directory 2 Name.Suite B Name
pabot does provide options to control the level of parallelism and the order of execution. It is described in readme file of the project:
.pabotsuitenames file contains the list of suites that will be executed. File is created during pabot execution if not already there. The file is a cache that pabot uses when re-executing same tests to speed up processing. This file can be partially manually edited. First 4 rows contain information that should not be edited - pabot will edit these when something changes. After this come the suite names.
There are three possibilities to influence the execution:
The order of suites can be changed.
If a directory (or a directory structure) should be executed sequentially, add the directory suite name to a row.
You can add a line with text #WAIT to force executor to wait until all previous suites have been executed.
Pabot Github
pabot is not working very well with a suite structure e.g. "01__B_Test" because it will be turned into “B_Test”. This means that suites will be executed in alphabetical order and not in numbering order. To fix this, all suites would have to be included in .pabotsuitenames to adjust the order again. With hundreds of suites, this is more than cumbersome.
Currently I'm working with Exasol database first time and came across one script which is responsible to run sql script written in .sql file.
Here is the script
C:\Program Files\EXASOL\EXASolution\EXAplus\exaplusx64.exe -configDir EXASolutionConfig -profile profile_PROD_talend -q -f D:/Data/Customer/PROD/EXASolution_SQL/EXASOL_data_script.sql -- databaseName tableName /exasolution/StageArea/fileName.csv
I want to know, how this script is working and what its doing actually ? What I understood so far is below
First "C:\Program Files\EXASOL\EXASolution\EXAplus\exaplusx64.exe " is starting a Exasol on command line and then its pointing to the script where .sql file is located.
Not getting:
1) What this part is doing "-configDir EXASolutionConfig -profile profile_PROD_talend -q -f "?
2) What are these identifiers doing "-q -f "?
3)After launching exaplusx64.exe, Is exasol going to connect with database and table name mentioned in script ? If then How cav file is paying its role in this script ? I mean in .sql there is just an sql statement, If its taking data from file then how ? I'm not getting this ..!!
Please share your comments
1) This where you say to Exasol to read the profile profile_PROD_talend in the folder EXASolutionConfig and execute the file D:/Data/Customer/PROD/EXASolution_SQL/EXASOL_data_script.sql in quiet mode (-q).
From the manual:
-configDir *This is not actually in the EXASOL manual, I assume it's the folder with the profiles, or maybe it does nothing*
-profile Name of connection profile defined in <configDir>/profiles.xml (profiles can be edited in the GUI version). You can use a profile instead of specifying all connection parameters.
-q Quiet mode which suppresses additional output from EXAplus.
-f Name of a text file containing a set of instructions that run and then stop EXAplus.
2) Quiet mode and flag for the name of the file.
3) When you run this command EXAPlus connects to the db using the information provided in the profile and it will execute the .sql file passed.
Now things become interesting, the -- allows you to pass some arguments to the .sql file. So you are passing three parameters (databaseName, tableName, and /exasolution/StageArea/fileName.csv). If you open the sql script you will find &1, &2, and &3, these are the placeholders for the parameters passed by your command.
From the manual again:
-- <args> SQL files can use arguments given over via the parameter “-- ” by evaluating the variables &1, &2 etc. .
For example, the file test.sql including the content
--test.sql
SELECT * FROM &1;
can be called in the following way:
exaplus -f test.sql -- dual
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.