Rename `Force Tags` to `Test Tags` and remove `Default Tags`

We currently have three settings for controlling tags tests get:

• Force Tags in the Settings section for specifying tags tests will unconditionally get.
• Default Tags in the Settings sections for specifying tags tests get, in addition to the forced tags, unless tests themselves have tags.
• [Tags] with each tests to specify tags they get in addition to the forced tags. These also override the default tags.

This is rather complicated and my understanding is that all three settings are rarely used. I propose we simplify this so that in the future we'd only have two settings:

• Test Tags in the Settings section to specify tags tests always get. Same as Force Tags nowadays.
• [Tags] with each test to specify tags tests get in addition to the Test Tags.

The functional difference compared to the current behavior is that there wouldn't be a possibility to specify tags tests get by default but that they could override when needed. For example, something like this wouldn't be possible anymore:

*** Settings ***
Force Tags      all have
Default Tags    most have

*** Test Cases ***
T1
    No Operation
T2
    [Tags]    only one has
    No Operation
T3
    No Operation

Instead of using Default Tags that some tests override, all tests that actually need these tags must list them explicitly. The change wouldn't be overly big and I actually like this better:

*** Settings ***
Test Tags      all have

*** Test Cases ***
T1
    [Tags]    most have
    No Operation
T2
    [Tags]    only one has
    No Operation
T3
    [Tags]    most have
    No Operation

This change is obviously backwards incompatible and cannot be done without a deprecation period. I propose we do it like this:

• In RF 5.1 add Test Tags that basically acts as an alias for Force Tags. Also document that Test Tags and [Tags] are the way forward.
• In RF 6.0 deprecate Force Tags and Default Tags.
• In RF 7.0 remove Force Tags and Default Tags.

This is currently only a proposal and comments are welcome! If you just want to indicate your opinion, you can add :+1: or :-1: reaction to this description.

One benefit of replacing Force Tags and Default Tags with just Test Tags would be consistency with other settings like Test Setup and Test Timeout. Tags would work slightly differently, though, because Test Tags and [Tags] would be combined together while, for example, [Setup] overrides Test Setup. We could obviously consider making it so that [Tags] would override Test Tags as well, but I believe that functionality wouldn't be as convenient.

Another benefit of replacing Force Tags and Default Tags with just Test Tags would be making localization (#4096) easier. Both Test and Tags need to be translated anyway, so most likely translating Test Tags wouldn't need any extra work. At least in Finnish translating Force Tags is somewhat problematic and this change would avoid that problem altogether. If we'd add Test Tags in RF 5.1, then translators could only translate that and forget Force Tags altogether. They could also decide to ignore Default Tags as it would be deprecated relatively soon anyway.

In case we have Test Tags, there also needs to be a Task Tags equivalent similar to Task Setup and Task Task Timeout, etc.

Just dropping this in, because the discussion above has no mention of RPA and it shouldn't be forgotten 😁

We could obviously consider making it so that [Tags] would override Test Tags as well, but I believe that functionality wouldn't be as convenient.

Voting NO to consider [Tags] would overwrite [Test Tags]. This will cause massive refactoring for users.

You @rikerfi vote "NO" for [Tags] overriding Test Tags (which I don't like myself) but aren't against the idea to rename Force Tags to Test Tags and removing Default Tags, right?

[Tags] overriding Test Tags would actually mean that we'd rename Default Tags to Test Tags and remove Force Tags.

@pekkaklarck You got me right. I love the original idea to rename Force Tags to Test Tags and remove Default Tags. That would be a step ahead.

Actually i do not see any advantages.

Test Tags or Force Tags are totally replaceable and non of those is 100% self explanatory.

but Force Tags give a hint on what it does. we do use Default tags. Most tags are defaulting to A but some are B. So we use Default Tags and [Tags] for this.

instead of changing that, i would like to see Suite Tags instead. So that really a suite has a tag.

I covered the main benefits of this change already earlier, but I summarize them here:

• Simpler syntax. I find that important in general and especially for new users.
• Test Tags would be consistent with Test Setup and other test related settings. With Force Tags and Default Tags it's not even clear are they related to tests.
• Localization gets easier. Terms Test and Tag need to be translated anyway while terms Force and Default are likely to be harder.

The main drawback would obviously be the removed functionality: you couldn't anymore set tags that most test have so that individual tests can override them. My understanding is that this isn't too widely used feature, but I'm sure there are usages out there.

One solution to this problem would be coming up with some new syntax that provides the same functionality. One possibility would be making it possible to remove tags using the [Tags] setting, for example, by using -tag syntax. We actually already support that with the Fail keyword that accepts an optional list of tags to add or remove. With that syntax the example in the description would look like this:

*** Settings ***
Test Tags      all have    most have

*** Test Cases ***
T1
    No Operation
T2
    [Tags]    only one has    -most have
    No Operation
T3
    No Operation

I think the above looks at least as good as the original. The basic functionality is easy to explain and understand (tags set with Test Tags and [Tags] are simply combined) and the special case how to remove tags with -tag is pretty simple as well.

Another alternative would be using some more explicit prefix like REMOVE: tag instead of -tag. It would avoid problems with someone possibly having tags starting with -. We could even use our reserved tags like robot: remove: tag, but that starts to look strange. Another possibility would have adding a special marker to denote that tags after it should be removed. It could look like

[Tags]    only one has    -    most have

or

[Tags]    only one has    REMOVE    most have

When discussing about tagging on Slack, @Snooz82 proposed adding Keyword Tags to make it easier to specify common tags for all keywords in a resource file. I think that's a good idea and submitted #4373 about it. If that's done, renaming Force Tags to Test Tags gets more important. I also don't think adding something like Default Keyword Tags would make sense regardless what we do with Default Tags and thus some other syntax for removing globally set tags would be really convenient. I submitted #4374 about the possible -tag syntax I already proposed above.

In this comment I'll explain the current proposals related to changing tag related settings, what I think should be the end goal, and what would be the first steps towards that. The proposals are:

• Rename Force Tags to Test Tags and remove Default Tags (this issue)
• #4373
• #4374

The motivation of the first proposal, renaming Force Tags to Test Tags and removing Default Tags, is making the syntax simpler, more consistent, and easier to translate. Most people seem to be in favor of renaming Force Tags and I personally find it especially important if we plan to implement the second proposal and add Keyword Tags. There are obviously backwards compatibility concerns, but we can support Force Tags as an alias for Test Tags for long time.

Removing Default Tags is more controversial because it would remove a concrete functionality. It wouldn't anymore be possible to specify tags that most tests have so that some tests could override them. That functionality doesn't seem to be that widely used, and it makes the whole tag setting system pretty complicated, but it would nevertheless be unfortunate to remove something that some people are using.

The proposal to add Keyword Tags is a good motivation to remove Default Tags, though. It would be somewhat confusing to have Test Tags, Keyword Tags and Default Tags, and I definitely don't want to add something like Default Keyword Tags to support default tags with keywords. Having a way to set default tags for keywords would nevertheless be convenient, and if it could be done without adding a new setting we could use that approach also with tests. That would then allow removing Default Tags without loosing functionality.

The third proposal, being able to remove tags set globally with -tag syntax, aims to provide the "default tags" functionality without extra settings and so that it would work both with tests and keywords. Unlike the current Default Tags that tests can override by having their own [Tags], this proposal would allow tests (and keywords) to opt-out from having some tags. In addition to making the Default Tags (and Keyword Default Tags) redundant, I consider this syntax easier to understand as well. I'm not absolutely sure is the -tag syntax best, though, or should we support something like REMOVE: tag instead. This is something to discuss further, but I believe something like this is better than having Default Tags.

:loudspeaker: I believe the end goal should be that we have only Test Tags and Keyword Tags settings for setting tags globally for tests and keywords. In addition to that it should be possible to use -tag syntax (or something similar) with tests/keywords that don't need certain tags. The steps I propose to reach the end goal are listed below by version.

RF 5.1

• Add Test Tags as an alias for Force Tags.
• Add Keyword Tags.
• Deprecate having tags starting with - like -tag in [Tags]. Escaping like \-tag should work if you really need such a tag.
• Explain all this in release notes.

RF 5.2 (Q4/2022)

• Add support for removing globally set tags in [Tags] by using the -tag syntax. If we have found some better syntax, use that instead.
• Mention all this in release notes again.

RF 6.0 (or later)

• Deprecate Force Tags.
• Deprecate Default Tags.

RF 7.0 (or later)

• Remove Force Tags. Could possibly preserved even longer as it's only an alias.
• Remove Default Tags.

The above timeline gives us plenty of time make the final decision about the fate of Default Tags. Before RF 6.0 we could preserve it just be changing the decision and reverting deprecation wouldn't be that big a problem either.

Changes planned for RF 5.1 are pretty safe as well. Keyword Tags is a useful feature, and if it's added Test Tags is clearly better Force Tags even if Default Tags would in the end be preserved. Deprecating literal -tag usage is easy to revert if we decide not to use that syntax for removing tags.

All this looks so safe to me that I plan to work with RF 5.1 changes pretty soon. If you have questions, concerns, or anything else, comment here or participate the discussion on the #devel channel on our Slack.

Been writing RF code since 2015. Have a lot. In the last year had to move from v3 to v5 quickly to pick up support for a few things. Been a lot of churn because of this. Understandable, but I wonder if the older user base is considered as much as it should be with almost capricious changes like this one proposed.

Remember for your user base RF is a tool. Not something they get involved at the dev feature level on any frequent basis except using it.

Another relevant example is robotidy. I have spent the last two days trying to get some similar functionality to robot.tidy. At this point I think I will have to write an External Transformer to get pipe separators back. Additionally in those two days I have found a number of bugs/issues with robotidy (see RF user group conversations for details) So was it ready to deprecate in 5.0? Not sure. Still trying to understand the new tool. (Note the Migrating from robot.tidy example in the docs comes no where near close to robot.tidy; and example has two syntax errors in it. :-) )

The overall point here is changing older stuff just to make it 'pretty' is a lot more cost for your user base than I believe is well understood.

RF has a great tag system. I use it everywhere. Would Test Tags look better than Force Tags? Yes, Force Tags always seemed like a language translation misunderstanding. But is the ROI there? Not so sure.

When you do this please provide in the release notes a clear example of how to use the RenameKeywords transformer with a regex to replace all Force Tags with Test Tags. Then all I have to do is the many days of a test cycle on my code base. :-)

(and I understand that new functionality is also proposed but basic [Tag] usage will be the same, right?)

Thanks for the time you guys put in. This is a great product. Love using it.

This issue exists to track the progress of renaming Force Tags to Test Tags and removing Default Tags. We have added Test Tags in RF 6.0 (#4368) and the -tag syntax in RF 7.0 (#4376). I believe we could loudly deprecate the old settings in RF 8.0 and moved this issue to its scope. Once we have a dedicated issues about deprecation and eventual removal, this issue probably can be closed.

@glueologist You have a very good point related to backwards compatibility. We do take it seriously, but in this particular case we believe changes are worth the problems they cause.

As you noted, Force Tags is a rather horrible name, but we didn't change it just because Test Tags is better. The main motivation was simplifying localization (#4096), it would have been stupid to require Force Tags to be translated to different languages and thus we introduced Test Tags in RF 6.0 along with localization.

Default Tags isn't as bad a name, but it isn't that great either and it also became ambiguous after we added Keyword Tags (#4373). Same functionality would be useful also with keywords, but we didn't feel like it would be worth adding Default Keyword Tags or something like that. The -tag syntax proposed in #4376 and implemented in RF 7.0 works with test and keyword tags feels much more natural.

These good reasons don't change the fact that the change is backwards incompatible. Good news is that we aren't in a hurry to remove the old syntax. It will work without deprecation warnings at least until RF 8.0 (late 2024 or early 2025) and actual removal will be happen much later. I would expect tools like RoboTidy to evolve so that they update this syntax automatically.

Thanks for taking the time to address my concerns. I did not consider localization when seeing this change. This consideration makes sense.

Thanks for all the effort. Great tool.