The extension currently has it's own logic to determine if tests are executable and/or testable;
- Targets defined with a rule named
test_suite are considered testable (can technically be incorrect if a rule with the same name is used, but very unlikely).
- Targets defined with a rule ending with a
_test suffix. This pattern is enforced in Bazel.
- All targets are considered executable, which is incorrect most of the time.
This results in invalid actions being advertised in codelens, etc.
An improvement can be made today using the query filter functions tests(...) (long available) and executables(...) (9.0.0 and 8.5.0) allow us to use Bazel's own definition of what is testable and executable.
However it is not currently possible to output multiple result sets from queries, so multiple queries would be required (3, up from 1). This has a non-negliable performance impact, especially in big workspaces.
To address the performance needs, I'm adding test and executable to the proto output in bazelbuild/bazel#27955. This approach should also simplify backward compatibility (no query change necessary, just falling back to inference when Bazel version is too low).
The extension currently has it's own logic to determine if tests are executable and/or testable;
test_suiteare considered testable (can technically be incorrect if a rule with the same name is used, but very unlikely)._testsuffix. This pattern is enforced in Bazel.This results in invalid actions being advertised in codelens, etc.
An improvement can be made today using the query filter functions
tests(...)(long available) andexecutables(...)(9.0.0 and8.5.0) allow us to use Bazel's own definition of what is testable and executable.However it is not currently possible to output multiple result sets from queries, so multiple queries would be required (3, up from 1). This has a non-negliable performance impact, especially in big workspaces.
To address the performance needs, I'm adding
testandexecutableto the proto output in bazelbuild/bazel#27955. This approach should also simplify backward compatibility (no query change necessary, just falling back to inference when Bazel version is too low).