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
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: