add yaml support for tests and glTF tests #387
Conversation
mattelser
requested review from
lilleyse,
weegeekps,
r-veenstra and
corybarr
as code owners
| } | ||
|
|
||
| ConfigMap getScenarioConfig(const std::string& scenario, YAML::Node configRoot) { | ||
| ConfigMap sConfig = ConfigMap(); |
There was a problem hiding this comment.
NIT: Could you come up with a better name for this variable than sConfig? Perhaps scenarioConfig?
There was a problem hiding this comment.
At the risk of bikeshedding: it would appear we have slightly different preferences for variable name length. I generally agree with your "it's not 1990" philosophy of properly spelling things out, which you mentioned the last time this came up. I usually aim for a "clear names, smaller where harmless" approach (partly because shorter lines means I can cram more tabs next to each other without scrolling/wrapping 😄 ). I think having the one config in a small function called getScenarioConfig be named sConfig is clear and concise, but am happy to conform to whatever the preferred style is!
| // YAML Config Examples | ||
| // ---------------------------------------------- | ||
|
|
||
| std::string transmogrifier(const std::string& s) { |
|
@mattelser could you add "Fixes #308" to the PR description so that it gets linked to that issue? |
Co-authored-by: Sean Lilley <lilleyse@gmail.com>
Fixes #308 . This sets up a workflow that I expect to use for future tests: establish expected results via a yaml config, then compare some function call to that expectation, repeat in various scenarios.
In this case, the "scenarios" are all different gltf models from the Khronos Group glTF asset generator meant for exactly such testing.
The best place to start a review will probably be in
ExampleTests.cpp, as this demonstrates (and simultaneously documents) the new workflow.