Package: rdbunit
RDBUnit: Unit testing for relational database queriesRDBUnitis a unit testing framework for relational database queries.
It allows you to express in a simple way the setup prior to a query,
the query, and the expected results.
RDBUnit can testSELECTqueries as well as queries that are used
for creating tables and views.
All types of queries can be either embedded into the test script, or
they can be included from an external file.
The tables for the input and the expected results can be created with
minimal ceremony: RDBUnit will automatically infer the types of the
tables' fields.For complex relational OLAP queriesRDBUnitcan be combined particularly
effectively with thesimple-rolaprelational online analytical processing framework.
You can find a complete tutorial on usingRDBUnitwithsimple-rolapfor mining Git repositories in atechnical briefingpresented at the 2017 International Conference on Software Engineering.You can cite this work as follows.Diomidis Spinellis. Unit Tests for SQL.IEEE Software, vol. 41, no. 1, pp. 31–34, Jan.-Feb. 2024. doi:10.1109/MS.2023.3328788.InstallationUsing PippipinstallrdbunitFrom sourceClone this repositorygit clone --depth=1 https://github.com/dspinellis/rdbunit.git
cd rdbunit
pipenv shell
pip install .Test specificationFor every SQL query you want to test, create anRDBUnitfile that
specifies the query's input, execution, and expected result.Simple exampleThe following example illustrates this concept.BEGIN SETUP
sales:
month   revenue
March   130
April   50
END

BEGIN SELECT
SELECT MAX(revenue) as max_revenue FROM sales;
END

BEGIN RESULT
max_revenue
130
ENDInput file detailsThe input and output and output are specified as table contents.
The input starts with a line containing the wordsBEGIN SETUP,
while the results start with a line containing the wordsBEGIN RESULTS.
The input and output are specified by first giving a table's name,
followed by a colon.
The name may be prefixed by the name of a database where the table
is to reside, followed by a dot.
The next row contains the table's fields, separated by spaces.
Then comes the table's data, which is terminated by a blank line,
or by the wordEND.
More than one table can be specified in the setup.
In the results the table name is not specified, if the tested
query is a selection statement, rather than a table or view creation.
The setup-query-results sequence can be specified multiple times within
a test file.Setup exampleBEGIN SETUP
contacts:
name    registered      value   reg_date
John    true            12      '2015-03-02'
Mary    false           10      '2012-03-02'
ENDResults example (named table)Named table results are used withCREATEqueries.BEGIN RESULT
leadership.nl_commits_leader_comments:
project_id      n
1               3
ENDResults example (unnamed set)Unnamed set results are used withSELECTqueries.BEGIN RESULT
name    registered      value   reg_date        a
John    True            12      '2015-03-02'    Null
ENDThe query to test is either specified inline with aBEGIN SELECT(for
selection queries) orBEGIN CREATE(for creation queries) statement,
or by including a file through the correspondingINCLUDE SELECTorINCLUDE CREATEstatement.Inline exampleBEGIN SELECT
SELECT *, NULL AS a FROM contacts WHERE registered;
ENDExternal query exampleINCLUDE CREATE nl_commits_leader_comments.sqlUnit testingTo run the tests runRDBUnitpiping its output to one of the supported
relational database systems (currentMySQL,PostgreSQL, andsqLite).
A number of command-line flags allow you to tailor the operation ofRDBUnit.
When running,RDBUnitwill report on its output something likeok 1 - recent_commit_projects.rdbu: test_stratsel.recent_commit_projectsfor each succeeding test case andnot ok 1 - project_stars.rdbu: test_stratsel.project_starsfor each failing
test case.
A final line will list the number of succeeding and failing test cases.
By defaultRDBUnitcreates and operates on temporary databases,
whose name is prefixed with the wordtest_.By specifying the--resultsoption (or the equivalent-rshort option)
you can directrdbunitto display the table generated for each test.
This is useful for debugging test failures or for generating reference data
(after suitable manual verification).Execution example (SQLite)$rdbunit--database=sqliterecent_commit_projects.rdbu|sqlite3
ok1-recent_commit_projects.rdbu:test_stratsel.recent_commit_projectsExecution example (MySQL)$rdbunitcommits_comments.rdbu|mysql-uroot-p-N
Enterpassword:
ok1-commits_comments.rdbu:test_leadership.nl_commits_leader_comments
ok2-commits_comments.rdbu:test_leadership.leader_commits_nl_comments
ok3-commits_comments.rdbu:test_leadership.commits_with_comments1..3Execution example (PostgreSQL)$rdbunit--database=postgresqlcommits_comments.rdbu|psql-Ught-h127.0.0.1-t-qghtorrentok1-commits_comments.rdbu:test_leadership.nl_commits_leader_commentsok2-commits_comments.rdbu:test_leadership.leader_commits_nl_commentsok3-commits_comments.rdbu:test_leadership.commits_with_comments1..3DevelopmentContributions via GitHub pull requests are welcomed.
Each contribution passes through continuous integration,
which verifies the code's style (pycodestyle) and checks for errors
(pylint).
It also tests the input and output ofRDBunitand its operation on the
three supported relational database systems.
On a local host, after creating a virtual environment (pipenv),
entering it (pipenv shell), and
installing the required development dependencies (pipenv install --dev),
you can run the following commands.``pycodestyle src/rdbunit/main.py`pylint src/rdbunit/__main__.pytests/test-parts.shtests/test-sqlite.sh