I got a projet that running on multiple environnement en production. So I got an identical test environment like the production.
I need to execute my RobotFramework tests on each of this test environnement, in parralel.
So my needs is to do these 3 task in parralel with only 1 execution, in parallel to not waste time..
robot -d rapport -v env:UAT1 tests/
robot -d rapport -v env:UAT2 tests/
robot -d rapport -v env:UAT3 tests/
I tried to use --argumentfile to do it, in each of them I added env:UAT1, env:UAT2, env:UAT3. It should execute the tests for each argumentfile but it doesnt work :
robot -d rapport --argumentfile UAT1.args --argumentfile UAT2.args --argumentfile UAT3.args tests/
I tried pabot but it doesnt seems to work too...
you can use the suite initialization file, to set your environment variables, and you can trigger it using a CMD variable.
Related
I have to run this command
./emsInventory.sh -s 10 -i EMS1004 -p EMS -v 10.2.0.15.1 -d "EMS Patch " -c ems10/pass_ems10#rac_ems10.agnity.com
In robot framework to make sure that data is created or not
Use the Run Process in the Process library - this is its precise purpose.
You can use SSH Library in robot framework more details can be found here http://robotframework.org/SSHLibrary/SSHLibrary.html.
Below examples could be useful
Execute Command And Verify Return Code
[Documentation] Often getting the return code of the command is enough.
... This behaviour can be adjusted as Execute Command arguments.
${rc}= Execute Command echo Success guaranteed. return_stdout=False return_rc=True
Should Be Equal ${rc} ${0}
Executing Commands In An Interactive Session
[Documentation] Execute Command always executes the command in a new shell.
... This means that changes to the environment are not persisted
... between subsequent Execute Command keyword calls.
... Write and Read Until variants can be used to operate in the same shell.
Write cd ..
Write echo Hello from the parent directory!
${output}= Read Until directory!
Should End With ${output} Hello from the parent directory!
I want to launch my test suite from a bash script using the & operator in background mode b/c I want my bash script to do something else while the test suite is running.
This doesn't seem possible ATM. What I see is:
$ dotnet test --filter "FullyQualifiedName~GenerateTransactions" >> dotnet.log 2>&1 &
[1] 2068
Tailing the log file for 5 minutes doesn't show me anything. Then pressing Enter in the terminal where I started the tests appears to show me that the dotnet process has stopped
$ <press Enter>
[1]+ Stopped dotnet test --filter "FullyQualifiedName~GenerateTransactions" >> dotnet.log 2>&1
Then I type fg and the dotnet process comes to the foreground and the log file immediatelly starts filling with output:
$ fg
dotnet test --filter "FullyQualifiedName~GenerateTransactions" >> dotnet.log 2>&1
So how do I make dotnet test detach from the controlling terminal/script ?
you can use nohup command to start you dotnet test
nohup dotnet test --filter "FullyQualifiedName~GenerateTransactions" >> dotnet.log &
I need to run the command line dotnet run, after starting the url localhost, I need to run another command like curl.
I could do like it:
dotnet run & sleep 12; curl http://localhost:59406
but if dotnet run delay more then 12 seconds, it will be stopped.
It may be possible to solve with linux commands, but I am not experienced in this.
If that helps, I will use this when building the Azure DevOps pipeline, to run newman tests on localhost
You can extend the sleep time if dotnet run takes longer to start up your application, to make sure your application is started when curl the url localhost
If you use this in azure devops pipeline, you can use two bash tasks to run above command. The first bash task run dotnet run & to start your application in the background. The second bash task run curl to curl url localhost. See below yaml pipeline example.
- bash: |
#cd ConnectionWeb/ConnectionWeb
#dotnet restore
dotnet run &
- bash: |
curl http://localhost:8881
We have a dotnet core script we use to index some files. We leverage RedHat Software Collection so items like dotnet can tie into our RHEL setup.
To run the script, we do the following:
source scl_source enable rh-dotnet30
/opt/rh/rh-dotnet30/root/usr/bin/dotnet /d/h/fileprocessor.dll 1
We want to run this in cron, but we can not get it to work. We have tried the following:
Adding the 'source' command to the bash profile, but this doesn't seem to be reliable for us, and not run on the cron event.
Running this directly in cron
Running this as a shell script in cron
We are at a loss, it seems we can never get the two commands to work together. If we don't include the source command, even if in our profile, it will not run and gives us the error " It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download"
The following works for me. I am using rh-dotnet31 (.NET Core 3.1) though, since rh-dotnet30 (.NET Core 3.0) is out of support:
Install packages:
$ sudo yum install rh-dotnet31 -y
Start at a known directory
$ cd ~
Create a directory for .NET Core source code to use
$ mkdir hello
$ cd hello
Create a simple application for testing
$ scl enable rh-dotnet31 bash
$ dotnet new console
$ dotnet publish
$ exit # this exits from the subshell started from scl enable command above
Copy the build over to a separate directory where we can run it
$ cp -a bin/Debug/netcoreapp3.1/publish ../hello-bin
Create the script that cron will invoke
$ cd ~
And put this in a ./test.sh file:
#!/bin/bash
echo "test.sh running now...."
source scl_source enable rh-dotnet31
dotnet $HOME/hello-bin/hello.dll 1
You could probably even combine the last two lines (source... and dotnet ...) into scl enable rh-dotnet31 -- dotnet $HOME/hello-bin/hello.dll 1
Then make it executable:
$ chmod +x ./test.sh
Set up the crontab file
$ crontab -e
And then add the line below in this file. This one runs the script every minute.
* * * * * $HOME/test.sh >> $HOME/test.cron.log 2>&1
On my machine, cron is running, so I now see the output of the cron job in the log file after a few minutes:
$ tail -f test.cron.log
test.sh running now....
Hello World!
test.sh running now....
Hello World!
test.sh running now....
Hello World!
test.sh running now....
Hello World!
test.sh running now....
Hello World!
The issue we ran into for this was that the runtime had only been installed, and not the SDK. Once the SDK was installed, which included many other dependencies, it just worked.
I want to use pcov instead of xdebug for code coverage generation.
I'm using Docker and I have xdebug installed.
Can I be sure that xdebug won't affect test execution if I run the following command?
php -d xdebug.default_enable=0 -d pcov.enabled=1 path/to/phpunit --coverage-text
I read that pcov might be faster but as I understood xdebug has to be disabled.
Is it better do the following to achieve the fastest coverage instead of running the above command?
remove/truncate xdebug config
run tests
php -d pcov.enabled=1 path/to/phpunit --coverage-text
restore xdebug config
Xdebug and PCOV both overload the same parts of the engine, as a result they are incompatible, and there's no sense in the authors trying to make them compatible.
Xdebug must not be loaded if you want to use PCOV as the driver for php-code-coverage.
Source: I wrote pcov ...
xdebug will cost performance even if disabled with:
xdebug.default_enable=0
The impact is not negligible.
You're better off disabling the xdebug extension completely before running your tests.
This will give you the best performance if you're using pcov to generate the code-coverage.
Is it better do the following to achieve the fastest coverage instead of running the above command? [disable/enable xdebug/pcov instead of loading them]
as you're running php on the commandline, you don't need to fiddle with ini files invoking phpunit.
instead you can make the runtime configuration explicit with command-line parameters, this offers an interesting effect often.
it works with the -n switch, that is disabling all configuration files (see php --help for usage info):
php -n [...]
where [...] stands for the arguments that are specifically for the use-case, in general and specific here for phpunit:
php -n <php-file> [<php-file-argument>...]
`------------ [...] --------------´
php -n path/to/phpunit --coverage-text
`--------- [...] -------------´
the -n switch/option makes the runtime really naked, so you start with a clean slate.
first of all running phpunit may not work at all and would not for some features (like reading the configuration file), because phpunit needs some php extensions and -n controlled to not load any php extensions (that is php only have the core extension or those that are compiled in and can not be deactivated).
Therefore you have to add them, e.g. Dom for the XML configuration file and Tokenizer for generating the HTML code-coverage report (soon):
php -n -d extension=dom -d extension=tokenizer [...]
Then your test-suite most likely also tests paths of your code that requires extensions. invoking phpunit will highlight these in failures. Therefore you have to add them (e.g. here json):
php -n -d extension=dom -d extension=tokenizer -d extension=json [...]
This is perhaps the interesting part, as you learn about the extension requirements your code has (at least for unit-testing).
Finally add the coverage extension of choice. Let's take pcov for the example:
php -n -d extension=dom -d extension=tokenizer -d extension=json \
-d extension=pcov -d pcov.enabled=1 [...]
and then you get your results:
PHPUnit 9.5.4 by Sebastian Bergmann and contributors.
Runtime: PHP 7.4.20 with PCOV 1.0.8
Configuration: phpunit-cfg.xml
............... 15 / 15 (100%)
Time: 00:00.191, Memory: 6.00 MB
OK (15 tests, 33 assertions)
Generating code coverage report in HTML format ... done [00:00.021]
Compare against xdebug? Why not:
hp -n -d extension=dom -d extension=tokenizer -d extension=json \
-d zend_extension=xdebug -d xdebug.mode=coverage [...]
^^^^^
and have the results:
PHPUnit 9.5.4 by Sebastian Bergmann and contributors.
Runtime: PHP 7.4.20 with Xdebug 3.0.4
Configuration: phpunit-cfg.xml
............... 15 / 15 (100%)
Time: 00:00.222, Memory: 8.00 MB
OK (15 tests, 33 assertions)
Generating code coverage report in HTML format ... done [00:00.024]
The hinted phpunit-cfg.xml file was one created with phpunit --generate-configuration and code-coverage enabled. The output examples have been shortened for clarity.