Currently the --contains option can (effectively) only be passed once on the command line (subsequent arguments seem to be silently ignored, which itself probably represents a defect). Also the provided filter string specifies a literal case-sensitive string match. This is not very flexible.
This feature would be more usable if:
--contains defaulted to case-INsensitive string matching, because that's probably what the end user usually wants--contains accepted a comma-delimited list of patterns (e.g. --contains=foo,bar) and/or supported passing the option multiple times (e.g. --contains=foo --contains=bar) where in both cases this would be interpreted as a logical OR filter (i.e. run tests with a name/description matching any provided pattern).--not-contains A new option to enable runtime skipping of known-broken tests. This could perhaps be used either in isolation (e.g. --not-contains=broken runs every test not matching "broken"), or in combination with --contains as an additional negative filter (e.g. --contains=foo,bar --not-contains=broken runs every test matching ("foo" OR "bar") AND NOT "broken")
One could certainly imagine more powerful options, ranging from introducing syntax to support logical-AND of --contains, to support for full regex pattern matching. However even just something akin to the initial few options sketched above would be an improvement and should hopefully not be too difficult to implement.
See also related issue #142
Currently the
--containsoption can (effectively) only be passed once on the command line (subsequent arguments seem to be silently ignored, which itself probably represents a defect). Also the provided filter string specifies a literal case-sensitive string match. This is not very flexible.This feature would be more usable if:
--containsdefaulted to case-INsensitive string matching, because that's probably what the end user usually wants--containsaccepted a comma-delimited list of patterns (e.g.--contains=foo,bar) and/or supported passing the option multiple times (e.g.--contains=foo --contains=bar) where in both cases this would be interpreted as a logical OR filter (i.e. run tests with a name/description matching any provided pattern).--not-containsA new option to enable runtime skipping of known-broken tests. This could perhaps be used either in isolation (e.g.--not-contains=brokenruns every test not matching "broken"), or in combination with--containsas an additional negative filter (e.g.--contains=foo,bar --not-contains=brokenruns every test matching ("foo" OR "bar") AND NOT "broken")One could certainly imagine more powerful options, ranging from introducing syntax to support logical-AND of
--contains, to support for full regex pattern matching. However even just something akin to the initial few options sketched above would be an improvement and should hopefully not be too difficult to implement.See also related issue #142