tests

FalconPy Unit Testing
The contents of this folder are used to unit test the FalconPy code base. Developers who are wanting to contribute to the FalconPy project can review this documentation for detail regarding how to unit test successfully so that pull request submissions are not delayed.
Available tests
A unit test is available for every Service Class implemented within FalconPy and are named after the Service Class module being tested.
There are also a few additional files and unit tests within this directory that are used as part of other unit tests, or to test certain library aspects to complete code coverage.
conftest.py
Pytest configuration file. Ignored.
coverage.svg
Generated coverage badge.
test_authentications.py
Tests authentication functionality and creates the authentication object used by all other unit tests.
test_authorization.py
Authorization, Service vs. Uber authentication and cross-cloud authentication testing.
test_timeout.py
Tests timeout handling functionality.
test_uber_api_complete.py
Tests the Uber Class.
testfile.png
Test file used for upload & download testing within the API.
Configuring your environment
In order to run unit testing successfully, you will need to configure your environment.
Development requirements
The necessary Python requirements for development and testing can be found in requirements-dev.txt. Install these requirements with the following command:
Environment variables
There are two required environment variables, and three optional environment variables used for unit testing. Set these before starting your test series.
Example
DEBUG_API_ID
Contains the CrowdStrike Falcon API client ID used for testing.
DEBUG_API_SECRET
Contains the CrowdStrike Falcon API client secret used for testing.
DEBUG_API_BASE_URL
Contains the CrowdStrike base URL used for requests to the API. Only required for unit testing in the CrowdStrike US-GOV-1 region. Specify usgov1 if you are testing in this region.
CROSS_DEBUG_KEY
Used to test cross cloud authentication. Contains a CrowdStrike API client ID. Can be left null, or set to the same value as DEBUG_API_ID
CROSS_DEBUG_SECRET
Used to test cross cloud authentication. Contains a CrowdStrike API client secret. Can be left null, or set to the same value as DEBUG_API_SECRET
API Scopes
Unit test series are designed to test every code path within every module of the library, meaning every method of every class. A single unit test series is over 200 individual unit tests, many of which make multiple requests to the CrowdStrike Falcon API. In order for unit tests to be successful, they will need API credentials scoped to allow them permissions to execute the operations they are performing. (Although many unit tests will accept credential failure as an allowed result.)
Developers should either limit their local unit testing to API service collections they are focused on, leveraging API credentials scoped to these collections, or use a development key that is scoped to all of the API service collections being tested.
An API credential scoped to every CrowdStrike API service collection is an extremely powerful token. This credential should be guarded closely with the secret rotated on a regular basis.
Running a single unit test
A single unit test can be executed using the unit-test.sh utility within the util folder.
From the main folder execute the following command where {unit_test_name} is the name of the service collection you are testing:
Example
For an example, let's run a unit test of the source of the Detects Service Class.
Result
Our test runs and results are provided immediately as they are produced.
Once the test completes, you are provided coverage results. Note how in this example, the Detects Service Class has 100% coverage. Since we are only testing the one Service Class in this example our coverage miss in the other Service Classes is expected.
For private modules such as the _endpoint or _payload submodules, or files such as __init__.py or _result.py, etc. coverage results should be ignore when performing singular unit testing.
Executing the entire unit test series
The entire unit testing series can be run using the run-tests.sh utility within the util folder.
From the main folder execute the following command:
Unit tests will be collected and then begin to execute in order.
When finished, testing results are displayed immediately before coverage is calculated.
Then coverage is displayed.
Finally, a bandit static code analysis is performed.
Checking code and docstring style
Two helper utilities are provided to assist you with confirming code quality and style.
lint.sh will lint the entire package.
Example
Result
docstyle.sh will check the formatting of docstrings within the source of the package.
Example
Result
Questions
Having trouble getting unit testing to perform the way you expect? Let us know, we're happy to assist.

WE STOP BREACHES
Last updated
Was this helpful?
