# dbprocessing

# 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