D. Unit testing

Unit testing

If you're working on the tools, you'll want to run the unit tests. The unit tests don't currently cover everything; right now, they're focused primarily on library routines and the like. We'll be enhancing them as time goes on.

Table of contents

• Unit testing
  • Unit test framework
  • Running the unit tests
  • Continuous integration

Unit test framework

We're using pytest for unit tests. If a particular package has unit tests, it'll have a test subdirectory. For example, there's a bdc/test directory, indicating that there are some unit tests for bdc.

Running the unit tests

You can use the ./run-tests.sh script at the top of the repo to run the unit tests. By default, it:

• Creates a local Python virtual environment, under .venv at the top of the repo, if it doesn't already exist. (It uses your currently active Python, so make sure Python 3.7 is in your path.)

• Installs the build tools (via python setup.py install), to ensure that the tools and their dependencies are available.

• Locates all the test subdirectories and runs pytest in each one.

Continuous integration

When a PR is opened or merged, the unit tests are automatically run, using Travis CI. To see the build history, visit https://travis-ci.org/databricks-edu/build-tooling.

Travis is configured using the .travis.yml file in the top of the repo. You can find Travis CI documentation at https://docs.travis-ci.com. You might find the Python project docs to be of particular interest .

The Travis CI builds (kicked off when a PR is opened) also use ./run-tests.sh. However, since Travis CI supplies its own virtual environment and automatically installs the build tools, the .travis.yml configuration file passes travis as the only argument to ./run-tests.sh, which causes the script to bypass those two steps.