In my RF tests in few places I have added logging by
log to console Scanning first UID ${pack_uids}[0]
But when I open HTML log file, I expected to see a value, which was used in this test. Instead I have exactly the text.
While Robot Framework can work with ${pack_uids}[0] stored as a variable, how can I get variable value, instead of plain text? I tried also to use Log only, same issue.
Similar case, when I try to log to file from Python file by running
logger.console("Some foo")
But as a result, this is not presented in log.html file at all.
And a side question, is it possible to get logs produced by each pabot thread in some file, like it's created in the console when running a single robot command?
Another option is to set the loglevel to INFO
In the command line use --loglevel option or the Set Log Level keyword
Of course I found it out just after placing the question... It's really important to have Log only, and the details are presented in a new line
In Python file use
logger.write("Log you want to include" + str(variable))
And it's working all fine. Just mind you need to expand the logging row
Related
I want to save my results in a specific folder for each running in robot framework.
I know there is a command call --outputdir which I also use.
But I want to know if there is any possibility to set the path for saving my results before in the robot script?
Thanks.
Best
psad
No, there is no way to do that.
The internal variables for paths are set as constants.
Also you should not have that approach because the test operations should be separated from the orchestration operations.
I am trying to trouble shoot an issue on an application running on flavor of UNIX.
The default logging level puts out a reasonable amount of messages and does not affect performance.
But where there is an issue I need to change the logging level to verbose. Thousands of line in a second. Which effects performance.
Doing a delete of the trace log file would crash the application.
Being able to change back the logging level as quick as possible helps avoid a production performance hit.
The code is running in production so a performance hit is not good.
How can one create a second instance of the log for just the second or two that the problem is reproduced?
This would save having to copy the whole large file and then doing an edit to remove log entries not of concern for the problem at hand?
I have answered my own question because I have found this tip to be very useful at times and hope it helps others.
The steps below show how to quickly get a small section of the log to a separate file.
1) Navigate to the directory with the log file that you want to clear.
cd /logs
2) At the command prompt enter the following line. e.g. (include the ">")
> trace.log
This will clear the file trace.log without a file pointer changing.
3) Now quickly reproduce the error.
4) Quickly go back to the command line and copy the trace.log file to a new file.
cp trace.log snippet_of_trace.log
5) Now you have a much small log to analyze.
I am using scalapact for CDC test.
My tests are running fine and the pact file is generated under target>pacts folder.
I have another folder "files" where I want those pact files to be generated after running the pact tests.
Is there any way I configure the default path for pact files?
This is an area that needs some attention in Scala-Pact, however, someone kindly did a PR for us a while ago that lets you set an environment variable called pact.rootDir.
In practice, on linux/mac that variable is a bit tricky to set because of the ., so exporting it or just using -Dpact.rootDir="<my desired path>" in the command arguments doesn't seem to work. Instead, you need to do this:
env "pact.rootDir=<my desired path>" bash. I haven't tried this on Windows so I don't know if you'd have the same issue.
I've just raised an issue to try and make this easier in the future:
https://github.com/ITV/scala-pact/issues/101
As an alternative, note that the pact directory is really kind of a scratch/tmp area to allow Scala-Pact to compile it's output. If you're running this as part of a build script, you may just want to add a step to copy the assets to a new location once they've been generated.
Also, for some reason we made reading from a directory way easier than writing to one. If you need to read from a dir such as during verification, you can just add --source <my desired path> on the command line.
Hope that helps.
I have recently started working on a program that should not be changed much and there are problems that it closes properly with Robot Framework. The method that came to my mind now was that I could get the reports before the test end.
So I have this Question:
Is there a possibility or keyword in Robotframework that I can use to get reports before the test is done?
Is there a possibility or keyword in Robotframework that I can use to get reports before the test is done?
No, there is not. Robot creates the reports as an in-memory xml document. It doesn't write the data to disk until the tests are finished. It then runs a post-processing step to convert them to html.
As #Bryan wrote, there is no way to get report.html during robot runtime as it is generated in postrun step.
However, you may use listener to get feedback from robot about execution status. For instance, in RED Robot Editor IDE, it is used to populate Execution View (see screenshot at the bottom):
http://nokia.github.io/RED/help/user_guide/launching/ui_elements.html
More about listener API: https://github.com/robotframework/robotframework/blob/master/doc/userguide/src/ExtendingRobotFramework/ListenerInterface.rst
When I am trying to copy the file 'Output.xml' from parent folder to target folder, it is not being copied properly i.e: the file size, in the target folder, is different. I am executing the keyword to copy files in my 'Suite Teardown'. Any solution for the issue.
Code written to copy files:
OperatingSystem.Copy Files ${sProjectPath}//output.xml ${sFinalFolder}
The problem is that while the test is running, the output file doesn't exist. It can't exist during suite teardown, because the result of the suite teardown must be part of the log.
If you need the log in another folder, the simplest solution is to tell robot to write it there initially, with the command line option --output or --outputdir.
If you cannot use --output, perhaps the simple solution is to create a script that runs your tests, and then copies the file after it runs. This is mentioned in the user guide in the section titled Creating start-up scripts.
A slightly more complex solution is to use a listener which copies the file in the done method.
Robot run reports are created at the end by robot-framework tool. Hence complete result/report files doesn't exist even in suite teardown.
Best practice would be providing --ouput argument with desired output dir.
More detail you can find from user guide
Robot framework user Guide under section 3.5.1
Note:
The command line option --output (-o) determines the path where the output file is created relative to the output directory. The default name for the output file, when tests are run, is output.xml.
Alternative way is use to rebot command and act on the output file generated by robot run.
When post-processing outputs with Rebot, new output files are not created unless the --output option is explicitly used.
Whether or not it can be done from Robot Framework script, the question is it should be done from Robot Script. These files could be locked and or changed by the current Robot Framework process. If not today, this could well be a part of any future change in this area.
With this perspective I can only recommend to copy these files prior to the start of Robot Framework, and not after. This ensures that the contents of these files are not changed and are fit for the purpose you have in mind.
As these types of actions are typically not part of a Test Case scenario I consider them to be part of the overarching Orchestration. This includes fetching the right version of the test script from version control software, starting Robot Framework, communicating results (ex. email) and safeguarding the test evidence (Log files and other files).
In general these are standard step functionality in a CI tool like Jenkins, Travis CI or Bamboo (to name a few). Even if you have only started on this path, separating this kind of logic from your test script will save you a lot of effort later on.
looks like that Copy Files Kw does not copy the content of output.xml during Teardown ,although it creates file with samename. As A.Kootstra suggested it could be a limitation currently.
Alternative:
in a separate robot script you can rename the file 'output.xml' generated from first script and then can run below command
Copy Files
${sProjectPath}//output.xml ${sFinalFolder}
This copies the whole content