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
Low Prio/Nice to have: add the possibility of passing xtc module paths to files instead of module names to the runner.x parallel test runner, and maybe other places needed for XUnit called through build interaction.
#172
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.
The "runner.x", i.e. the parallel XTC test runner module takes a list of module names only, as arguments to run in parallel. If it could be modified to support paths to actual xtc module files, instead of their names, we could very nicely generate calls to the parallel test tasks by just passing the included source set outputs instead of module names, that run the risk of including or excluding some module names that are no longer present in the test suite or the source set. It also shows that we can do something powerful with the build system.
This is not a high priority report, or a bug or anything, but it's little "nice to have" feature request that can be done wherever. I suspect that its ramifications are wider and more generic than just modifying a test harness class, that may be replaced with e.g. the XUnit framework later. I see several situations when wanting to compute which modules to process / launch / compile would benefit from being able to be passed as the paths to their modules. It is an operation that would likely be re-used quite a lot for things like unit- and integration test frameworks. Especially, as the build system has no knowledge of what module name a generated xtc file contains. I'm sure that info can be grabbed by calling methods in Javatools, but it's probably not a good idea to weaken the strict abstraction barrier between build and javatools execution.
The text was updated successfully, but these errors were encountered:
The "runner.x", i.e. the parallel XTC test runner module takes a list of module names only, as arguments to run in parallel. If it could be modified to support paths to actual xtc module files, instead of their names, we could very nicely generate calls to the parallel test tasks by just passing the included source set outputs instead of module names, that run the risk of including or excluding some module names that are no longer present in the test suite or the source set. It also shows that we can do something powerful with the build system.
This is not a high priority report, or a bug or anything, but it's little "nice to have" feature request that can be done wherever. I suspect that its ramifications are wider and more generic than just modifying a test harness class, that may be replaced with e.g. the XUnit framework later. I see several situations when wanting to compute which modules to process / launch / compile would benefit from being able to be passed as the paths to their modules. It is an operation that would likely be re-used quite a lot for things like unit- and integration test frameworks. Especially, as the build system has no knowledge of what module name a generated xtc file contains. I'm sure that info can be grabbed by calling methods in Javatools, but it's probably not a good idea to weaken the strict abstraction barrier between build and javatools execution.
The text was updated successfully, but these errors were encountered: