We love and welcome contributions!
In order to maintain a high quality, we run a number of checks on different OS / Compiler combinations, and using different analysis tools.
Building and testing sentry-native
currently requires the following tools:
- CMake and a supported C/C++ compiler, to actually build the code.
- python and pytest, to run integration tests.
- clang-format and black, to format the C/C++ and python code respectively.
- curl and zlib libraries (e.g. on Ubuntu: libcurl4-openssl-dev, libz-dev)
pytest
, clang-format
and black
are installed as virtualenv dependencies automatically.
$ make setup
This sets up both git, including a pre-commit hook and submodules, and installs a python virtualenv which is used to run tests and formatting.
$ make format
This should be done automatically as part of the pre-commit hook, but can also be done manually.
$ black tests
$ make test
Creates a python virtualenv, and runs all the tests through pytest
.
Running integration tests manually:
$ pytest --verbose --maxfail=1 --capture=no tests/
When all the python dependencies have been installed, the integration test suite can also be invoked directly.
The maxfail
parameter will abort after the first failure, and capture=no
will print the complete compiler output, and test log.
Running unit tests:
$ make test-unit
Unit tests also have a dedicated make
target, if they need to be run separately
from the integration tests.
Running unit tests manually:
$ cmake -B build -D CMAKE_RUNTIME_OUTPUT_DIRECTORY=$(pwd)/build
$ cmake --build build --target sentry_test_unit
$ ./build/sentry_test_unit
The unit tests are a separate executable target and can be built and run on their own.
The way that tests are run unfortunately does not make it immediately obvious from the summary what the actual failure is, especially for compile-time failures. In such cases, it is good to scan the test output from top to bottom and find the offending compile error.
When running tests locally, one can use the --maxfail=1
/ -x
parameter to
abort after the first failure.
The integration test suite runs the sentry_example
target using a variety of
different compile-time parameters, and asserts different use-cases.
Some of its behavior is controlled by env-variables:
ERROR_ON_WARNINGS
: Turns on-Werror
for gcc compatible compilers. This is also the default forMSVC
on windows.RUN_ANALYZER
: Runs the code with/through one or more of the given analyzers. This accepts a comma-separated list, and currently has support for:asan
: Uses clangs AddressSanitizer and runs integration tests with thedetect_leaks
flag.scan-build
: Runs the build through thescan-build
tool.code-checker
: Uses theCodeChecker
tool for builds.kcov
: Useskcov
to collect code-coverage statistics.valgrind
: Usesvalgrind
to check for memory issues such as leaks.gcc
: Use the-fanalyzer
flag ofgcc > 10
. This is currently not stable enough to use, as it leads to false positives and internal compiler errors.
TEST_X86
: Passes flags to CMake to enable a 32-bit (cross-)compile.ANDROID_API
/ANDROID_NDK
/ANDROID_ARCH
: Instructs the test runner to build using the given AndroidNDK
version, targeting the givenAPI
andARCH
. The test runner assumes an already running simulator matching theARCH
, and will run the tests on that.
Analyzer Requirements:
Some tools, such as kcov
and valgrind
have their own distribution packages.
Clang-based tools may require an up-to-date clang, and a separate clang-tools
packages.
CodeChecker
has its own
install instructions
with a list of needed dependencies.
Running examples manually:
$ cmake -B build -D CMAKE_RUNTIME_OUTPUT_DIRECTORY=$(pwd)/build
$ cmake --build build --target sentry_example
$ ./build/sentry_example log capture-event
The example can be run manually with a variety of commands to test different
scenarios. Additionally, it will use the SENTRY_DSN
env-variable, and can thus
also be used to capture events/crashes directly to sentry.
The example currently supports the following commands:
capture-event
: Captures an event.crash
: Triggers a crash to be captured.log
: Enables debug logging.release-env
: Uses theSENTRY_RELEASE
env-variable for the release, instead of a hardcoded value.attachment
: Adds an attachment, which is currently defined as theCMakeCache.txt
file, which is part of the CMake build folder.stdout
: Uses a custom transport which dumps all envelopes tostdout
.no-setup
: Skips all scope and breadcrumb initialization code.start-session
: Starts a new release-health session.overflow-breadcrumbs
: Creates a large number of breadcrumbs that overflow the maximum allowed number.capture-multiple
: Captures a number of events.sleep
: Introduces a 10 second sleep.add-stacktrace
: Adds the current thread stacktrace to the captured event.disable-backend
: Disables the build-configured crash-handler backend.before-send
: Installs abefore_send()
callback that retains the event.discarding-before-send
: Installs abefore_send()
callback that discards the event.on-crash
: Installs anon_crash()
callback that retains the crash event.discarding-on-crash
: Installs anon_crash()
callback that discards the crash event.override-sdk-name
: Changes the SDK name via the options at runtime.stack-overflow
: Provokes a stack-overflow.http-proxy
: Uses a localhostHTTP
proxy on port 8080.socks5-proxy
: Uses a localhostSOCKS5
proxy on port 1080.
Only on Windows using crashpad with its WER handler module:
fastfail
: Crashes the application using the__fastfail
intrinsic directly, thus by-passing SEH.stack-buffer-overrun
: Triggers the Windows Control Flow Guard, which also fast fails and in turn by-passes SEH.