You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the unit tests depend on the overarching components as well as underlying vulkan GPU objects. This of course is suboptimal for unit tests and would benefit from having a set of mocks for the core and vulkan classes. This may require migrating from Catch2 to Google Test.
The text was updated successfully, but these errors were encountered:
Currently exploring abstraction of VulkanHPP classes via KhronosGroup/Vulkan-Hpp#734; text from issue below (currently waiting for response):
Hello, I am currently looking for best practices to create mocks for the Vulkan HPP library to be able to test individual components of a library I'm currently working on, and wanted to get your thoughts on what woudl be the best practice, or the most common approach to this, particularily around building mocks for the Vulkan classes. Currently some ways I have been able to identify how mocks could be written for vulkan classes are below.
The ideal approach would be if Vulkan HPP could come wtih parent interfaces that implemented the methods as virtual so they could be extended with mocks, however given that all the functions are configured to be templated in order to pass the Dispatch class I understand it would be harder to achieve.
The current approach I started exploring is creating a separate mock classes that could be linked on the tests so these can be used instead during the tests themselves. This unfortunately would be virtually impossible as it would require re-defining all the classes that are used from the vulkan HPP classes.
Another option is to extend the current classes to expose the vulkan HPP classes as template arguments in the application, so they can be swapped at compile time, but this would be sub-optimal given it would require all classess to be templates (which would require all definitions in header file or limitations of template types with forward definitions), as well as add extra complexity for users having to define the template parameters (even if default parameters are provided as the vulkan hpp classes).
Do you have some insights on how people are currently approaching this with VulkanHPP? Thank you.
Now that #114 added swiftshader, this won't be necessary at this point, as that creates a CPU compatible component which was the main motivation for this issue. Because of this, closing this issue.
Currently the unit tests depend on the overarching components as well as underlying vulkan GPU objects. This of course is suboptimal for unit tests and would benefit from having a set of mocks for the core and vulkan classes. This may require migrating from Catch2 to Google Test.
The text was updated successfully, but these errors were encountered: