You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Krista Bennett e45d51242d
Fixed 2.1 legacy header issue
2 years ago
convenience_scripts First parts of zee testing are through 3 years ago
python_tests tests: python: Update readme. 2 years ago
src Fixed 2.1 legacy header issue 2 years ago
test_files ENGINE-935: added test (EncryptSignDirectLoopTest) which can be #if'd in to the test suite to check mem leaks on encrypt_and_sign 2 years ago
test_keys Committing to merge 2 years ago
test_mails ENGINE-938: Added notifyHandshake callback and status 2 years ago
tmp Cleaning up tests 3 years ago
Makefile Reverted changes to gtest-parallel - It's admittedly a nice idea, but nowhere else in the engine to we ever make any assumptions that the builds are taking place online or about what the builder has on the system. Reverting. 2 years ago Reverted changes to gtest-parallel - It's admittedly a nice idea, but nowhere else in the engine to we ever make any assumptions that the builds are taking place online or about what the builder has on the system. Reverting. 2 years ago Added dir creation and script for gpg socket dir to default 4 years ago A whole bunch of canonical emails generated with various target pEp versions and open PGP - intentionally broken files are in *wrong*.eml 2 years ago ENGINE-633: tests on ID collisions fixed to remove dependence on key election - need to revisit TOFU case once next week's release has happened. 3 years ago
pEpEngineTest.vcxproj Through the power of revert, fixed the modes I messed up in the last commit (sorry, new machine and dorking around caused an unintended large-scale mode reset) 4 years ago

Building and Running the Tests for the p≡p Engine

Work in progress.

Caveat, before you begin

Right now, the engine tests only function on *nix-like systems (including MacOS).

(Conversion to Windows will require, at the very least, looking at some of the file-handling code. If you want to fix this, start by looking in in the test/src directory!)


In addition to the engine requirements, you will need:

  • cmake
  • python3
  • git (for getting the gtest-parallel repository, unless you grab the tarball from somewhere)

Building the prerequisites

The Engine test suite now requires (at least) two additional pieces to run:

  • googletest
  • gtest-parallel

How this proceeds depends on your platform and whether or not you use a packaged distribution.

These instructions do this with cmake. If you can manage it with bazel instead, more power to you ;)

Installing googletest

Packaged distributions

This is the currently preferred way to do this, because everyone was doing it anyway and who am I to judge?

Debian and Ubuntu (and derivatives)

Thanks to Erik Smistad for this starting point (condensed from Getting Started with Google Test On Ubuntu):

  1. Install the packages cmake and libgtest-dev from the repository. This will install the gtest source files to /usr/src/gtest. You'll still need to compile the code and link the library files to be able to use them.

  2. Compile the source files:

cd /usr/src/gtest
sudo cmake CMakeLists.txt
sudo make
  1. Copy/symlink the libraries to the library location of your choice (here, it's /usr/lib, hence the sudo, but as long as it's in your library path, it shouldn't matter where you stick it):
sudo cp *.a /usr/lib
  1. Install package gtest from Macports

  2. Macports will build the libraries for you.

  3. In the next major section ("Building the Test Suite"), under "Makefile and local.conf", set GTEST_SRC_DIR to /opt/local/src/googletest in local.conf (see instructions below)

  4. Make sure /opt/local/lib is in your library path when compiling and linking the tests.

Downloading and compiling the source yourself

  1. Get the source, Fred. (Luke is tired of the source, I hear.)
git clone
  1. Switch into the source directory and find the directory containing the src and include directories. Mark this directory for later. (For me, this is ./googletest/googletest)

  2. Edit CMakeLists.txt here to contain the following line at the top:


(If you don't, it won't compile, and I will shake my fist at you.)

  1. Execute, in this directory:
cmake CMakeLists.txt
  1. In the lib directory of your current directory are located the library files you'll use (lib/*.a). Copy or symlink them to the library location of your choice (make sure this is a directory that can be seen during the test build process - i.e. one that's in one of the library paths used in building. Mine are located in $HOME/lib.

  2. See Makefile and local.conf under "Building the test suite" below - In this scenario, I set GTEST_SRC_DIR as <clone_path>/googletest/googletest (i.e. the absolute path of where the src and include directories were above - for me, /Users/krista/googletest/googletest).

Installing gtest-parallel

Pick a source directory and put your gtest-parallel source there (e.g. via git clone

We'll deal more with this when preparing to compile the test suite.

Building the test suite

Makefile and local.conf

So local.conf in the top-level engine directory is where we stick all of the Makefile overrides. The test Makefile contains some defaults for relevant variables here, but if you need to override them, please either create or modify local.conf in the top-level engine directory as needed. The relevant variables are:

  • GTEST_SRC_DIR: This is the directory where you compiled googletest above (defaults to /usr/src/gtest)

  • GTEST_INC_DIR: This is where the include files for googletest are located (defaults to $(GTEST_SRC_DIR)/include)

  • GTEST_PL: This is the full path to the python file for gtest_parallel (default presumes you cloned it under src in your home directory, i.e. it is $(HOME)/src/gtest-parallel/


Presuming the above works, then from the top test directory, simply run make.

Running the test suite

To simply run the test suite and see what tests fail...

Do one of:

  1. make test OR

  2. python3 <path to> ./EngineTests

To run individual test suites, especially for debugging purposes

Note that for some test suites, this will, if something goes dreadfully wrong, mean that one test's failure may pollute another test. This generally means you have found a dastardly bug in the engine, but it can also be a test issue.

Caveat lector.

  1. To run sequentially, in the same process:
./EngineTests --gtest_filter=TestSuiteName*

For example, for DeleteKeyTest:

./EngineTests DeleteKeyTest*
  1. To debug the same with lldb:
lldb ./EngineTests -- --gtest_filter=TestSuiteName*
  1. To debug with gdb:
gdb --args ./EngineTests --gtest_filter=TestSuiteName*

To run and/or debug individual test cases

  1. To run:
./EngineTests --gtest_filter=TestSuiteName.test_function_name

For example, for check_delete_single_pubkey in DeleteKeyTest:

./EngineTests DeleteKeyTest.check_delete_single_pubkey
  1. To debug the same with lldb:
lldb ./EngineTests -- --gtest_filter=TestSuiteName.test_function_name
  1. To debug with gdb:
gdb --args ./EngineTests --gtest_filter=TestSuiteName.test_function_name

N.B. The gtest_filter can be globbed and will run all matching tests; if you want to run every test in a test suite, be sure to use TestSuiteName*.

(Different shells will require different quoting styles for this - YMMV.)

When debugging a failing test, use '--gtest_break_on_failure' to have gtest automatically break into the debugger where the assertion fails.


Compile tests with -DDEBUG_OUTPUT to (possibly) see output to cout. May only work in the tests run directly from ./EngineTests (with or without filter)

Creating new tests

Script next on the agenda...

Known Problems

The normal run of the tests in parallel eats output. Try running the individual test case as above if you need to see a test case's output.