Robot Framework is a generic open-source test automation framework for acceptance testing, acceptance test-driven development (ATDD) and robotic process automation (RPA).
It has easy-to-use tabular test data syntax and it utilizes the keyword-driven testing approach. You can build the automated script by integrating all necessary built-in, third-party keywords and users can create new higher-level keywords from existing ones using the same syntax that is used for creating test cases.
In previous blog, I have introduced how to customize your own keywork libraries. Here I’ll continue to talk about extending Robot Framework – the listener interface.
Listener interface
Robot Framework has a listener interface that can be used to receive notifications about test execution. For example: external test monitors, sending a mail message when a test fails, communicating with other systems, modifying tests and results during the test execution.
Listeners are classes or modules with certain special methods, and they can be implemented both with Python and Java. Listeners that monitor the whole test execution must be taken into use from the command line. In addition to that, test libraries can register listeners that receive notifications while that library is active.
Next, I will use Python as the coding language to demo how to take listeners into use.
Taking listeners into use
By calling the command line with the –listener option give the name of the listener as an argument. the test suites/cases can be executed with listener enabled. The listener name is got from the name of the class or module implementing the listener.
Some other CLI options:
Listener interface methods
Robot Framework creates instances of listener classes when the test execution starts and uses listeners implemented as modules directly. During the test execution different listener methods are called when test suites, test cases and keywords start and end. Additional methods are called when a library or a resource or variable file is imported, when output files are ready, and finally when the whole test execution ends. A listener is not required to implement any official interface, and it only needs to have the methods it actually needs.
The methods and arguments are explained in the following table.
| Method | Arguments | Documentation |
|---|---|---|
| start_suite | data, result | Called when a test suite starts. data and result are model objects representing the executed test suite and its execution results, respectively. |
| end_suite | data, result | Called when a test suite ends. Same arguments as with start_suite. |
| start_test | data, result | Called when a test case starts. data and result are model objects representing the executed test case and its execution results, respectively. |
| end_test | data, result | Called when a test case ends. Same arguments as with start_test. |
| log_message | message | Called when an executed keyword writes a log message. message is a model object representing the logged message. This method is not called if the message has level below the current threshold level. |
| message | message | Called when the framework itself writes a syslog message. message is same object as with log_message. |
| output_file | path | Called when writing to an output file is ready. path is an absolute path to the file. |
| log_file | path | Called when writing to an log file is ready. path is an absolute path to the file. |
| report_file | path | Called when writing to an report file is ready. path is an absolute path to the file. |
| xunit_file | path | Called when writing to an xunit file is ready. path is an absolute path to the file. |
| debug_file | path | Called when writing to an debug file is ready. path is an absolute path to the file. |
| close | path | Called when the whole test execution ends. With library listeners called when the library goes out of scope. |
Listener examples
Getting information
Following example writes all the information into a text file.
Modifying execution and results
Following example gives the test case an execution timeout, if the case duration longer than default value the test result always set to fail.
Conclusion
With the powerful extensions and plugins, Robot Framework can reduce script creation time, save costs and enable manual engineers to complete automatic script creation.
Find us to know more about Robot Framework and test automation best practices.
