third_party_vulkan-loader/tests
Charles Giessen f8709399e1 Use builders in test framework components
Make use of BUILDER_VALUE and BUILDER_VECTOR in the various structs of the test
framework. This allows easier usage of the components by allowing a builder
style continuation of setting parameters in the drivers and physical devices.
2021-12-10 17:08:23 -07:00
..
framework Use builders in test framework components 2021-12-10 17:08:23 -07:00
CMakeLists.txt Update loader to include handle validation 2021-11-19 10:32:13 -07:00
loader_alloc_callback_tests.cpp test: Add test for memory leak in setup_tramp_phys_devs 2021-09-09 12:15:49 -06:00
loader_get_proc_addr_tests.cpp Revert to old behavior in GIPA for old apps 2021-12-02 18:57:29 -07:00
loader_handle_validation_tests.cpp Fix handle validation crash in RenderDoc 2021-12-02 08:46:14 -07:00
loader_layer_tests.cpp test: Update WrapObjects test to new framework 2021-10-07 10:00:08 -06:00
loader_regression_tests.cpp Add test for no drivers and no physical devices 2021-12-10 17:08:23 -07:00
loader_testing_main.cpp Fix test framework leaking registry entries 2021-12-02 22:15:32 -07:00
loader_threading_tests.cpp test: Fix compiler warnings in MSVC 2021-11-04 12:19:14 -06:00
loader_unknown_ext_tests.cpp Add test for unknown physical device functions 2021-11-08 15:15:31 -07:00
loader_version_tests.cpp test: Fix compiler warnings in MSVC 2021-11-04 12:19:14 -06:00
loader_wsi_tests.cpp test: Improved Test Wrapper interface 2021-09-06 18:19:14 -06:00
README.md test: Update tests/README.md 2021-08-04 09:57:16 -06:00

Loader Tests

This directory contains a test suite for the Vulkan loader. These tests are not exhaustive — they are expected to be supplemented with other tests, such as CTS.

(NEW) Running Tests

For most purposes ctest is the desired method of running tests. This is because when a test fails, ctest will automatically printout the failing test case.

Tests are organized into various executables:

  • test_regression - Contains the vast majority of tests.
  • test_wsi - These test require presentation engine support.
    • Because the test suite is meant to be run in CI, these test require extra work to make happen and thus live in their own executable.
  • test_threading - Tests which need multiple threads to execute.
    • This allows targeted testing which uses tools like ThreadSanitizer

The loader test framework is designed to be easy to use, as simple as just running a single executable. To achieve that requires extensive build script automation is required. More details are in the tests/framework/README.md. The consequence of this automation: Do not relocate the build folder of the project without cleaning the CMakeCache. Most components are found by absolute path and thus require the contents of the folder to not be relocated.

(OLD) Running Tests

To run the tests, your environment needs to be configured so that the test layers will be found. This can be done by setting the VK_LAYER_PATH environment variable to point at the built layers. Depending on the platform build tool you use, this location will either be ${CMAKE_BINARY_DIR}/tests/layers or ${CMAKE_BINARY_DIR}/tests/layers/${CONFIGURATION}. When using Visual Studio, a the generated project will already be set up to set the environment as needed. Running the tests through the run_loader_tests.sh script on Linux will also set up the environment properly. With any other toolchain, the user will have to set up the environment manually.

Writing Tests

The test_environment.h/cpp are the primary tool used when creating new tests. Either use the existing child classes of FrameworkEnvironment or create a new one to suite the tests need. Refer to the tests/framework/README.md for more details.

IMPORTANT NOTES:

  • NEVER FORGET TO DESTROY A VKINSTANCE THAT WAS SUCCESSFULLY CREATED.
    • The loader loads dynamic libraries in vkCreateInstance and unloads them in vkDestroyInstance. If these dynamic libraries aren't unloaded, they leak state into the next test that runs, causing spurious failures or even crashes.