Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create mocks to isolate unit tests for components #8

Closed
axsaucedo opened this issue Aug 28, 2020 · 2 comments
Closed

Create mocks to isolate unit tests for components #8

axsaucedo opened this issue Aug 28, 2020 · 2 comments
Labels
enhancement New feature or request triage Issue still needs to be discussed, researched and scoped

Comments

@axsaucedo
Copy link
Member

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.

@axsaucedo axsaucedo added enhancement New feature or request triage Issue still needs to be discussed, researched and scoped labels Aug 28, 2020
@axsaucedo
Copy link
Member Author

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.

@axsaucedo
Copy link
Member Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request triage Issue still needs to be discussed, researched and scoped
Projects
None yet
Development

No branches or pull requests

1 participant