Tests¶
There are two types of testing done with this project. Unit tests, which test if the individual pieces work, and functional tests, which test if the pieces work together
Unit Tests¶
Unit Tests are located in the tests/ directory.
To check test coverage (i.e., how many lines of code are actually hit by the tests):
python-coverage run test_all.py
python-coverage html
firefox htmlcov/index.html
Of course, instead of test_all.py, you can specify the name of the module you want to test.
Unit tests use the version of dbprocessing modules in the build directory,
i.e. run python setup.py build before running the unit tests.
Some unit tests access databases of sample information. These are built
on the fly. Sqlite databases are used unless PGDATABASE is defined.
In that case, it is the name of a Postgresql database to use instead.
- PGDATABASE¶
Name of a Postgresql database to use for unit testing. Must exist but be empty (i.e., no tables). See Specifying a database for other environment variables controlling this connection. All tables will be removed from this database at the end of unit testing!
On Windows, certain tests (test_move_SymLink in test_DBfile)
require elevated privileges to pass.
Functional Tests¶
Located in test_DB/ is a functional test. The goal was to have the simplest test of dbprocessing so testing is quick and complete without having to use real data.
Level 0 files are just simple words stored in testDB_{set}_(first|sec).raw format.
Level 1 files are the concatenated versions of level 0, stored in testDB_{set}.cat format.
Level 2 files are rot13’d versions of the level 1 files, and are stored in testDB_{set}.rot format.
testDB/scripts/runThisThing.sh will execute the needed scripts to run the entire dbprocessing chain.
The functional test uses the installed version of dbprocessing.
Release: 0.1.0 Doc generation date: Feb 10, 2022