The Database Library for Robot Framework allows you to query a database and verify the results.
It requires an appropriate Python module to be installed separately - depending on your database, like e.g. oracledb
or pymysql
.
The library consists of some keywords designed to perform different checks on your database. Here you can find the keyword docs.
Wath the talk at Robocon 2024 about the Database Library update.
oracledb
pip install robotframework-databaselibrary
*** Settings ***
Library DatabaseLibrary
Test Setup Connect To My Oracle DB
Keywords Connect To My Oracle DB Connect To Database ... oracledb ... db_name=db ... db_user=my_user ... db_password=my_pass ... db_host=127.0.0.1 ... db_port=1521
Test Cases Get All Names ${Rows}= Query select FIRST_NAME, LAST_NAME from person Should Be Equal ${Rows}[0][0] Franz Allan Should Be Equal ${Rows}[0][1] See Should Be Equal ${Rows}[1][0] Jerry Should Be Equal ${Rows}[1][1] Schneider
Person Table Contains Expected Records ${sql}= Catenate select LAST_NAME from person Check Query Result ${sql} contains See Check Query Result ${sql} equals Schneider row=1
Wait Until Table Gets New Record ${sql}= Catenate select LAST_NAME from person Check Row Count ${sql} > 2 retry_timeout=5s
Person Table Contains No Joe ${sql}= Catenate SELECT id FROM person ... WHERE FIRST_NAME= 'Joe' Check Row Count ${sql} == 0
See more examples in the folder `tests`.
# Handling multiple database connections
The library can handle multiple connections to different databases using *aliases*.
An alias is set while creating a connection and can be passed to library keywords in a corresponding argument.
## Example
```RobotFramework
*** Settings ***
Library DatabaseLibrary
Test Setup Connect To All Databases
Test Teardown Disconnect From All Databases
*** Keywords ***
Connect To All Databases
Connect To Database
... psycopg2
... db_name=db
... db_user=db_user
... db_password=pass
... db_host=127.0.0.1
... db_port=5432
... alias=postgres
Connect To Database
... pymysql
... db_name=db
... db_user=db_user
... db_password=pass
... db_host=127.0.0.1
... db_port=3306
... alias=mysql
*** Test Cases ***
Using Aliases
${names}= Query select LAST_NAME from person alias=postgres
Execute Sql String drop table XYZ alias=mysql
Switching Default Alias
Switch Database postgres
${names}= Query select LAST_NAME from person
Switch Database mysql
Execute Sql String drop table XYZ
The Connect To Database
keyword allows providing the connection parameters in two ways:
You can use only one way or you can combine them:
Along with commonly used connection parameters, named exactly as keyword arguments, a config file can contain any other DB module specific parameters as key/value pairs. If same custom parameter is provided both as a keyword argument and in config file, the keyword argument value takes precedence.
The path to the config file is set by default to ./resources/db.cfg
.
You can change it using an according parameter in the Connect To Database
keyword.
A config file must contain at least one section name -
the connection alias, if used (see Handling multiple database connections), or
[default]
if no aliases are used.
[default]
db_module=psycopg2
db_name=yourdbname
db_user=yourusername
db_password=yourpassword
db_host=yourhost
db_port=yourport
[myoracle]
db_module=oracledb
db_name=yourdbname
db_user=yourusername
db_password=yourpassword
db_host=yourhost
db_port=yourport
[default]
db_password=mysecret
[default]
my_custom_param=value
Keywords, that accept arguments assertion_operator
and expected_value
,
perform a check according to the specified condition - using the Assertion Engine.
Check Row Count SELECT id FROM person == 2
Check Query Result SELECT first_name FROM person contains Allan
Assertion keywords, that accept arguments retry_timeout
and retry_pause
, support waiting for assertion to pass.
Setting the retry_timeout
argument enables the mechanism -
in this case the SQL request and the assertion are executed in a loop,
until the assertion is passed or the retry_timeout
is reached.
The pause between the loop iterations is set using the retry_pause
argument.
The argument values are set in Robot Framework time format - e.g. 5 seconds
.
The retry mechanism is disabled by default - retry_timeout
is set to 0
.
${sql}= Catenate SELECT first_name FROM person
Check Row Count ${sql} == 2 retry_timeout=10 seconds
Check Query Result ${sql} contains Allan retry_timeout=5s retry_pause=1s
Keywords, that fetch results of a SQL query, print the result rows as a table in RF log.
Set Logging Query Results
.You can also setup the limit or disable the logging during the library import.
*** Settings ***
# Default behavior - logging of query results is enabled, log head is 50 rows.
Library DatabaseLibrary
# Logging of query results is disabled, log head is 50 rows (default).
Library DatabaseLibrary log_query_results=False
# Logging of query results is enabled (default), log head is 10 rows.
Library DatabaseLibrary log_query_results_head=10
# Logging of query results is enabled (default), log head limit is disabled (log all rows).
Library DatabaseLibrary log_query_results_head=0
While creating a database connection, the library doesn't explicitly set the autocommit behavior - so the default value of the Python DB module is used. According to Python DB API specification it should be disabled by default - which means each SQL transaction must contain a dedicated commit statement, if necessary.
The library manages it for you:
Execute SQL String
perform automatically a commit after running the query - or a rollback in case of errorQuery
don't perform a commit, but also do a rollback in case of errorYou can turn off this automatic commit/rollback behavior using the no_transaction
parameter.
See docs of a particular keyword.
It's also possible to explicitly set the autocommit behavior on the Python DB module level -
using the Set Auto Commit
keyword.
This has no impact on the automatic commit/rollback behavior in library keywords (described above).
The library is basically compatible with any Python Database API Specification 2.0 module.
However, the actual implementation in existing Python modules is sometimes quite different, which requires custom handling in the library. Therefore there are some modules, which are "natively" supported in the library - and others, which may work and may not.
oracle_driver_mode
parameter.