Test selections are a way of encoding subsets of tests, across all tests/suites that are defined, e.g. by metadata matching, by name, by type. One can then choose to run all tests within such a selection (similar to how you choose to run tests within a suite), or to run all tests that don't match a certain selection. This means that selections can be negated, which fixes the common anti-pattern of defining suites that either match or don't match a certain criteria, in order to have complimentary suites (e.g. fast vs slow tests).
This would also provide a solution to #31 by having the concept of a "default" selection, that defaults to all test suites, but can be redefined.
This is a feature we've been thinking/talking about for quite some time, see an earlier draft pitch document here: https://nextjournal.com/lambdaisland/pitch-test-selections
Test selections are a way of encoding subsets of tests, across all tests/suites that are defined, e.g. by metadata matching, by name, by type. One can then choose to run all tests within such a selection (similar to how you choose to run tests within a suite), or to run all tests that don't match a certain selection. This means that selections can be negated, which fixes the common anti-pattern of defining suites that either match or don't match a certain criteria, in order to have complimentary suites (e.g. fast vs slow tests).
This would also provide a solution to #31 by having the concept of a "default" selection, that defaults to all test suites, but can be redefined.