Closed Odonno closed 1 month ago
I'm OK for includeTags
for global config and feature and to set tags to Set<string>
.
I will keep @
for tags but as optional like @ignore
or ignore
. It's to prevent a breaking change, what do you thing ?
But I don't see nested tags (AND, OR) useful. I saw it on jest-cucumber for example, but I see that useless.
Well, I don't see why you are talking about breaking change. From reading the code, I saw you automatically remove the @
prefix before using it. It's ok to me. My change is, for example, to replace @ignore
by ignore
as people are usually thinking of tags with the @
. So, it's more of being developer friendly and handling all cases, whether they use the @
or not for excludeTag/includeTag
.
Well, for the case of nested tag filtering. it is for when you have hundreds of tests with an extended use of tags. Some have multiple tags and you'd like to only run the tests that both have @a
and @b
for example. I know this is a niche feature but I believe this is something that can be expected. Overall, it does not bring much complexity and it is not as complex as the parsed string cucumber expression. I really like the includeTags
and excludeTags
, nesting is just a useful extension only when it's needed.
Ok, you're right for both features. I'm reviewing code and I will test it on my projects before merge it.
2000 tests passes, everything is OK ;). I merge, publish a version and I'm going to update doc about tags.
includeTags
from config (global or per feature) because sometimes we want to exclude/ignore scenarii by tags but sometimes we only want some specific scenarii (for example when we are working on a new feature or to test a set of repetitve failing tests)AND
andOR
(I have added a jsdoc to demonstrate how that works)@
suffix because we can sometimes forget it and can be cumbersome if that is not handled, small but important improvementtags
to be aSet<string>
to both improve performance and dedup the array of tags automatically